Anyone familiar with boats knows that for a number of years, seamen have been using GPS devices that, taking into account tides, currents, wind direction and weather, chart the most fuel efficient course to your destination. These devices have saved boaters thousands of dollars in fuel costs, not to mention the thousands of grams of CO2 they saved from going into the atmosphere.

Now, something similar is happing in EVs. It’s called AutOS, and it’s the on-board software system BetterPlace unveiled this week at the Frankfurt motor show. Using Microsoft’s “Windows Embedded” system and Intel’s Atom Processor, AutOS will run on the video display of a head unit designed by German engineering company Continental and will be installed in every BetterPlace-compatible car.

On a basic level, this MMI (man-machine interface) will manage the car’s multimedia, climate control, and show the battery’s charge status and remaining range. On a not-so-basic level, AutOS will display all the charging stations in the surrounding area, and will even tell you which ones use clean power. It will also display all the nearby battery-swap stations, and, if needed, will allocate a battery for you in advance at one of these swap stations, so that a fully-charged battery’s waiting for you when you get there.

What is most cool about the AutOS though is its intelligent navigation system. Drivers simply plug in their intended destination, and, taking into account traffic patterns, the car’s range, and charging/battery-swap stations, AutOS will plot the most energy- and time-efficient route. Meaning drivers will get to where they want to go as quickly and as cheaply as possible – with the least amount of electrons expended, and without any worry of ever running out of juice!

For a demonstration of how the AutOS could improve your life, check out this video:

La versión soportada es Windows Embedded Standard 2009, misma que es frencuentemente utilizada en puntos de venta, terminales (ATM’s) y clientes livianos (thin clients).

Ahora podrán monitorear estos dispositivos, al igual que lo hacen con el resto de equipos de la compañía.

Más detalles en el siguiente link.

Felipe Román

Não, não é lá o que eu pensei. Eu tinha recebido um e-Mail da Microsoft ontem com um convite pra entrar no CTP do Windows Embedded 2011. Alegre eu resolvi baixar, instalei hoje mas não é lá o que eu pensei. Eu pensei que fosse estar recheado de recursos e coisas novas mas não tinha muitas mudanças …Logo ao abrir o instalador você vai avançando até chegar numa parte que você tem que selecionar o que quer que seja instalado com o Windows.
Passando isso a instalação começa vale ressaltar que a instalação pode ser tanto rápida ou tanto lenta pois depende do que você seleciona pra ser instalado, uma outra coisa é que nessa parte você pode selecionar se vai ou não instalar o Internet Explorer e o mesmo acontece com o Windows Media Player. A instalação minima ou seja sem nada só vai usar no disco rigido em torno de 660Mb isso sem nenhum driver adicional selecionado pra instalar também. Já com drivers fica entre 800mb e 1.1Gb. Nessa parte eu selecionei o que precisava e queria ou seja o suficiciente, sem coisas inuties que eu não uso. Mesmo assim ficou em 2.2Gb ficou muito e a instalação demorou uma hora e alguns minutos.
Depois disso quando ele foi entrar no Windows (Ele tem a mesma boot do Windows 7.) Apareceu as configurações finais (nome de usuario, senha, data e etc.) depois disso ele realmente vai ao Windows. A primeira vista sua logon é a mesma que o Windows 7 só que por infelicidade é sem o fundo e as coisas ainda em termos visuais pioraram pelo menos pra mim, embora ele tenha os temas do Windows 7 eles não funcionam no mesmo.
Algo notavel também é que ele é até um pouco mais rapido do que o Windows 7, ele teve um desempenho bom, leve e estável.

Essa build do Windows Embedded tem o mesmo kernel do Windows 7 na build 7231.
Versão 6.1.7231 (Build 7231.0.x86fre.winmain.090608-1900) Indica que foi compilada no dia 08/06/2009 e também uma outra diferença é que a data de expiração desta build foi adiada em relação ao Windows 7 RC. Ela vai expirar 15/08/2010 em 8:59 PM.

Check also:

Windows Embedded Standard 2009 Step-by-Step Deployment – Part I

Windows Embedded Standard 2009 Step-by-Step Deployment – Part II

After reviewing the necessary steps for preparing our environment (Post I) and building a custom image for a thin client (Post II); we’ll prepare the remote boot process as well as the remote boot server that will deploy that image on diskless devices.

If you prepared the same environment with the XP Embedded version, the process does not have much differences.

1. Set the Image Ready

Even though the building process of the image is complete, we need to run a few steps to set the image ready for deployment.

The First Boot Agent (FBA) needs to be executed one time to complete this process. By booting the image one time, the FBA makes a hardware detection and finishing some other tasks like network configuration. Also, these tasks executed by the agent can be customized; check this link about FBA. 

The image is already built, so we are going to take those files to a new disk (virtual in my case) and boot a client machine from there.

1.1 Add a second disk to the machine acting as Remote Boot Server. Create a new partition and set it to “Active”.

1.2 Copy the image files to that new logical disk.

1.3 Like I said, I’m using a virtual environment, so my next step would be to create a new virtual machine, attach the virtual hard disk as primary and start the virtual machine.

Since FBA contains several tasks to execute, could take a few moments to complete.

Soon as it completes, this message should appear: “Machine Released! Click to shutdown or reboot.”.

1.4 Select “Shutdown”. And I bet the next window will get you back some good old memories

Here comes an important note if you are planning a remote boot environment:

Since we’ve added the “System Cloning Tool” component and the image task sequences are now complete, every time this image is now booted will generate a new computer name, SID and other tasks that the fbreseal process executes to guarantee that there’ll be no cloned images on your environment. Quite similar as the sysprep process.

And it means that this image cannot be booted any more, otherwise the fbreseal process will be lost for next deployments.

1.5 Now you can attach the virtual disk back to the Windows Embedded remote boot server.

2. SDI Loader

The Storage Device Image Loader will be in charge of emulating those set of files to act as booteable storage for your clients.

2.1 Open SDI Loader from Windows Embedded Studio.

2.2 Click “Yes” to install the SDI Driver.

2.3 Click on “Add Disk” to generate a new .sdi file where the image will be stored.

2.4 Choose name and location for the file.

2.5 Choose the size of the file. This .sdi file should be, at least, 25% bigger than the image size.

Once it’s selected, the new device is added to SDI Loader and to your operating system as a new drive.

2.6 Open “Disk Management” to prepare the new virtual drive added to the system. Initialize disk.

2.7 Prepare the new volume following the wizard selecting it as “Primary Partition”.

2.8 Copy the image files (from the virtual disk that was used to boot one time) to the new virtual partition.

3. SDI Manager

Ok, now it is time to use some of options from the SDI Manager, that let us handle offline .sdi files.

We will generate a new SDI file that “Remote Boot Manager” will use to deploy on remote devices and machines.

3.1 Open a “cmd” and locate Windows Embedded Utilities “C:\Program Files\Windows Embedded\utilities”.

3.2 Create a new .sdi file using “SDImgr.wsf: cscript SDImgr.wsd /new c:\ramdisk.sdi”

With the new file created, the next step is to read the image files located in the virtual partition (in my case, this partition is associated with the F:\ drive) to complete the process.

3.3 From “cmd” run: “cscript SDImgr.wsf c:\ramdisk.sdi /readpart:F:”

64bits Operating System Issue

The SDI driver has an issue if you are using x64 operating system, like Windows Server 2008. If you try running any of the SDI Manager options, like the ones mentioned above, you will see this error:

“ActiveX component can’t create object: ‘SDIAUT.SDI’”

Even though the script used by x86 and x64 operating systems is the same, on a 32bit environment you won’t see this issue.

4. Configuring Remote Boot Manager

Remote Boot Manager and the DHCP role configured earlier, will be in charge of answering remote and diskless clients with the proper boot image.

4.1 Place the “ramdisk.sdi” file configured earlier inside this folder “C:\Program Files\Windows Embedded\Remote Boot Service\Downloads”.

4.2 Open "Remote Boot Manager” from Windows Embedded Studio.

4.3 Click “Yes” to create a new configuration file.

Once the Remote Boot Manager window opens, you need to add each client device or machine with their specific MAC Address. For that, we’ll take a look at the virtual machine client’s configuration.

4.4 To achieve booting from the network when you are using Hyper-V, you need to add a “Legacy Network Adapter” on the client machine and specify an static MAC Address.

4.5 With that, you are ready to complete the data from Remote Boot Manager.

Client MAC Address: Assigned statically.
Description: (optional).
Boot Server: Default value (0.0.0.0) to select local machine.
Boot Program: startrom.n12. This program will request F12 confirmation for booting from the network. You can also select startrom to access directly to the boot image without requiring confirmation.
Boot Image: ramdisk.sdi. Remember that the image should be placed inside “C:\Program Files\Windows Embedded\Remote Boot Service\Downloads”.
Boot Parameters: (optional).

Now your environment is set to go.

Make sure that your client machine has the correct configuration to boot from the network.

Loading the image remotely.

Windows Embedded image booting.

Desktop ready for use.

Enjoy!

Check also:

Windows Embedded Standard 2009 Step-by-Step Deployment – Part I

Windows Embedded Standard 2009 Step-by-Step Deployment – Part II

Cheers!

Check also:

Windows Embedded Standard 2009 Step-by-Step Deployment – Part I

Windows Embedded Standard 2009 Step-by-Step Deployment – Part III

After reviewing Post I we’ve set our environment to start building the images.

The process it’s practically the same that we executed on XP Embedded (Post I, Post II and Post III). And again, as I mentioned before, this deployment is oriented to Embedded images booting on diskless devices, so there will be steps that are not necessary if you are not looking for a remote boot environment with Windows Embedded Standard 2009 images.

Building the Image

1. Get hardware information from your target

This step is done with Target Analyzer, that is just an .exe file that compiles all of the hardware necessary information to be included on the image you are building. With the information gathered here, the corresponding drivers will be added to the image.

Since I’m using virtual machines in the same physical server, I’m going to collect hardware data in the same machine where I’m going to build the target image.

1.1 Open a cmd and focus on “C:\Program Files\Windows Embedded\utilities”.

1.2 Run “tap.exe”.

You’ll see that the program recollects information about your devices, and creates a new file on the same folder called “devices.pmq” containing all that data. 

Target analyzer collecting information

The files devices.pmq contains all the hardware information

2. Adding the Drivers to the Image

The image builder from the Windows Embedded Standard 2009 suite is still Target Designer.

2.1 Open Target Designer from Windows Embedded Studio.

2.2 Select create a new image and we are going to name it Embedded2009

Now you have to start creating the image from scratch and the first thing we are going to do is import the hardware information we gathered from Target Analyzer.

2.3 From “File” menu select “Import” and select “devices.pmq” created recently.

2.4 On the “Import File” window click “Start” and the importing process will begin.

Once it’s completed, you can check any warnings generated. In my case, there are several warnings regarding virtual machines synthetic drivers, those can be ignored for now.

The image now is loaded with a bunch of hardware components that the image will use.

3. Using Design Templates and Adding Components

3.1 Check on the Target Designer left pane and expand the “Design Templates”.

Here you’ll find common templates used when you are creating Embedded images. To find more information about each one, right click on the component and select “Help”.

I’m going to select the “Thin Client” component. You can drag and drop the objects to your customized image or right-click and select “Add”.

This component will generate the necessary requirements that, when the dependency check is run, will add other components included on the database. We’ll see that step later on this post.

Since we are using a remote boot environment, two special components are needed to achieve it: RAM Disk Driver (will allow booting from RAM) and System Cloning Tool (will include a kind of sysprep step, called fbreseal, to make each image unique and avoid cloning SID, computer name, etc each time is deployed).

3.2 From the left pane, use the “Search” box and insert “RAM Disk Driver”.

3.3 The component is shown. Right-click on it and select “Add”.

3.4 Repeat the step for “System Cloning Tool” component.

Here’s the chance for you to add any other special component that you want on your image.

.Net Framework 3.5

Silverlight 1.0

Or even more, you can set some of the components properties at this stage. For example: Windows Firewall.

Access Windows Firewall component settings

In here you’ll find much more options that the ones shown on XP Embedded

Turn on/off the Firewall by default on your image

Setting Firewall’s exceptions

Authorizing applications

Opening ports

4. Checking and Solving Dependencies

The main step of the building process is checking the dependencies that are created soon as you add a component to your image.

At this point you’ve configured your image with the proper drivers, customized it adding components and setting their properties; now let’s check what dependencies are been set.

4.1 From “Configuration” select “Check Dependencies”.

4.2 In the “Dependency Check” windows click on “Start”.

The process will start, it will take a few moments to complete. At the end of the process, you’ll see in the lower pane window all the messages that need attention before building the image.

Just double click on each of them to select the proper component to be added and solve the dependency.

Here are some of the common messages that you should see:

Component: “Base Component”. To solve it I’m selecting an standard component “Standard PC”.

Component: “Compression and Expansion Tools”. Solving it with “NTFS” component.

Component: “Regional and Language Options”. “English Language Support” to resolve.

Component: “Windows Logon”. I’m selecting “Explorer Shell”.

Soon as you click on “Add” on your last dependency, your image would seem to be ready to the build process, but not quite.

Since you’ve add new components with the dependency check, it’s highly recommended that you run the dependency check again for the new ones.

Soon as you finish this new “Dependency Check” and new and highly important component will appear to be added.

Select your boot loader. In my case I’m using the default loader for XP and 2003 environments: “NT Loader”. If you are trying to protect from any change to your boot environment, you can select “EWF NTLDR” component.

5. Building the Image

Ok, now that we’ve resolved all of the dependencies on our image, we can start building it.

5.1 From “Configuration” select “Build Target Image”.

5.2 Select the folder where the image will be stored. The default folder is “C:\Windows Embedded Images”. Click on “Build”.

Once the build process is complete, you can check the files and folders created.

And verify the image size. In my case is 255mb.

Now the image is completed and ready to be used on any of your targets.

Check the next post about preparing the same image for remote boot on diskless devices.

Check also:

Windows Embedded Standard 2009 Step-by-Step Deployment – Part I

Windows Embedded Standard 2009 Step-by-Step Deployment – Part III

Cheers!

Check also:

Windows Embedded Standard 2009 Step-by-Step Deployment – Part II

Windows Embedded Standard 2009 Step-by-Step Deployment – Part III

I’ve been reviewing, for a while now, the opportunities that Embedded operating systems has to offer. If you take a look to previous posts of mine that I’ve prepared about XP Embedded you’ll find a quick introduction to the platform + the steps for building, preparing and deploying XP Embedded images in your environment, including deploying it on diskless devices (remote boot):

Preparing and Installing Windows XP Embedded Images – Part I: Setting up the Environment

Preparing and Installing Windows XP Embedded Images – Part II: Building Images

Preparing and Installing Windows XP Embedded Images – Part III: Using Remote Boot

Windows Embedded 2009 Standard Overview

Windows Embedded 2009 Standard is the newest version of the Embedded operating systems released by Microsoft, succeeding Windows XP Embedded. These operating systems are oriented to special devices or computers, where you need a secure, small, reliable and manageable OS. WES 2009 contains the same kernel as Windows XP with a few improvements:

• Windows XP kernel with SP3 included
• Internet Explorer 7
• Windows Media Player 11
• Silverlight 1.0
• .Net Framework 3.5 (including also 1.0, 1.1 and 2.0).
• IPv6 support

For more information about Windows Embedded Standard 2009 check the following links:

- Windows Embedded Standard 2009 Home
- [PDF] Windows Embedded Standard 2009 Overview
- [PDF] Windows Embedded Standard 2009 Datasheet
- [PDF] Windows Embedded Kiosk Solutions
- Download Windows Embedded Standard 2009 Trial

So, after a quick review, let’s start with the step-by-step guide for building and deploying Windows Embedded 2009 Standard images, including the remote boot process.

Requirements

We will consider installing all the WES roles within the same machine, including the DHCP server (necessary for the remote boot environment).

Valid Operating Systems

- Windows XP Pro SP2 or higher
- Windows Server 2003 SP1 or higher
- Windows Vista
- Windows Server 2008

Roles

- DHCP Server available on the network
On our case we’ll have this role on the same machine.

 

Valid Database Engines

- SQL Server 2005 SP1 or higher
- SQL Server 2005 Express Edition SP1 or higher *
- SQL Server 2008
- SQL Server 2008 Express Edition

* : Windows Embedded Standard 2009 installation media already includes the SQL Server 2005 Express Edition SP2.

 

 

 

DHCP Configuration

Remember that this role and configuration it’s used only to achieve remote boot on diskless devices. It’s to necessary if that’s not your environment.

The same procedure used for XP Embedded is needed. Check this link for more information.

C:\WINDOWS\system32>netsh
netsh>dhcp
netsh dhcp>server \\<server_machine_name>
netsh dhcp>add optiondef 60 PXEClient String 0 comment=PXE support
netsh dhcp>set optionvalue 60 STRING PXEClient 

To verify the correct configuration, an option should be added and set on your DHCP server. You can check it on the DHCP Snap-In > Server Options.

Windows Embedded 2009 Standard Installation Step-by-Step

Well the process is quite simple, so you should not have any problem following it. But you’ll probably find a small issue within the procedure, let’s take a look:

1. Using the WES 2009 media, start the wizard from the autorun menu.

2. Insert the Product Key that you were given when you registered for the download.

3. Select “Custom” installation.

4. On the components to be installed, check also the entire feature for “Remote Boot Service”.

5. For the TFTP server, select “On this machine”.

6. Accept the default directory and click on “Next”.

7. Now select the SQL Server where the DB should be stored. I’m selecting it the local SQL Server Express instance already installed. Click on “Next”.

8. On the summary click on “Install”.

Here’s where you should find a problem. In the middle of the installation process this message will appear:

Windows Embedded Standard Error: WeUpdate. 
D:\Setup\WMP11.exe failed. Return value = 0×40

(Also the message could appear using other components besides WMP11, Windows Media Player).

The log file should have this message:

Windows XP Embedded Service Pack 3 Installer
Cannot connect to the database – please check the database.
Setup cannot continue.
No objects or files were imported to the database (local)\SQLEXPRESS.
WEUpdate Exiting with return code: 64
*** End of Run ***  

Solution

Wait 5-10 minutes and click on “Retry”.

You don’t believe it? Check this MSDN article about it. It’s related about how the installer access and closes the database during the installation process.

After that the installation should complete normally and you can access Windows Embedded 2009 Standard from the Start Menu.

We’ll review the rest of the process on the following posts.

Check also:

Windows Embedded Standard 2009 Step-by-Step Deployment – Part II

Windows Embedded Standard 2009 Step-by-Step Deployment – Part III

Cheers!

After what we’ve seen on the previous posts: Setting up the environment (Part I) and building an Windows XP Embedded Image (Part II) we can complete the remote boot process with diskless devices with this last part.

There are special hardware requirements for this procedure and could get a little tricky. In the computer you are using to prepare the image (the server), you need an additional hard disk (or virtual disk) which you will use to boot the image from.

To prepare the image for remote booting:

1. Add a second drive to the machine that act as server. Format the volume and set it like an “Active” partition.

2. Copy all of the files that were created on the Windows Embedded Images subfolder you chose to a second disk (virtual disk if you are using virtual machines)

Note: Since this disk will be used to boot an operating system image, remember that the partition within must be Active. Otherwise the operating system will not boot.

3. After copying all of the files to the second hard disk, move it to a client machine and boot that client using the disk.

4. After the image boots, you’ll see that several components are configured in the image, by a process named First Boot Agent. This process takes a few minutes to complete.

If you are using the System Cloning Tool, then fbreseal is run in the first boot, as the last step of the First Boot Agent. As stated before, if the image is rebooted afterwards, the image gets a new name and SID, so the reseal process is lost. As you need to keep it for diskless computers, don’t reboot after you see the following message. Turn off the computer instead.

5. After shutting down the computer, remove the disk and place it as the secondary disk on the computer you use for creating the image. That is the image that will be uploaded to the remote boot server and downloaded by each diskless client.

Using SDI Loader and SDI script

Now that you have the operating system resealed in the secondary disk, it’s time to create the SDI image. You will create two SDI files, one for storing the image as it is copied from the physical (or virtual) disk, and a second one that will store the final image that the clients will use for remote booting.

1. Open SDI Loader from Start | All Programs | Microsoft Windows Embedded Studio

2. Click on Add Disk

3. As you are creating a new SDI, type the name of a new file (like xpe-partition.sdi) and select Add

4. Since the file is new, a dialog will ask if you’d like to create the file. Answer Yes

5. The next step is to set the image size. The image size must be:

a. At least the size that the files on the resealed disk + some space for temporary files

b. At most half of the total system RAM (ie, if the client has 512mb of RAM, the image limit is 256mb)

c. There is a practical image limit of 500mb. Beyond that, it is likely that the image won’t boot.

This SDI file represents the partition that hosts the operating system. Set the image size and click OK

6. After the SDI file is created, a new virtual disk will be automatically added to the server. The disk needs to be partitioned, formatted and mounted. From the Control Panel | Administrative Tools open Computer Management. Select the Disk Management item from the left pane

a. The following dialog will appear notifying of the new disk. Click on Next

b. Make sure the disk is selected and click on Next

c. Since you won’t use a dynamic disk, leave the disk unmarked in the following screen, and click on Next

d. Click on Finish to close the dialog

e. Right click on the newly created disk and choose New Partition

f. In the wizard that opens, click on Next

g. Choose Primary partition type and click on Next

h. Leave the maximum partition size and click on Next

i. Assign a letter to it (like F) and click on Next

j. Make sure that the selected File system is NTFS and click on Next

k. Click on Finish to format the disk.

7. With the partition created, move the files from the disk that was used for the first boot to the virtual partition

8. Optionally, if you need to add additional files to the disk, you can copy them in this step.

9. The next step is to create a remote bootable disk, based on the virtual disk you completed in the previous step. To do that, you will use the SDImgr.wsf script, located in the Windows Embeddedutilities folder.

Open a command prompt and type the following (each command in a line):

cd “c:Program FilesWindows Embeddedutilities”
cscript SDImgr.wsf /new c:ramdisk.sdi
cscript SDImgr.wsf c:ramdisk.sdi /readpart:F:

Replace F: by the unit letter in which you mounted the virtual partition.

Note: All the explorer windows must be closed, including the Disk Management snap-in. When this procedure is running, the script tries to lock (exclusively) the partition and if some program is using it, the procedure will fail.

10. After completing the process, you will have a working remotely-bootable disk, stored on C:ramdisk.sdi. To make it deployable by the Remote Boot Manager, copy the file to C:Program FilesWindows EmebeddedRemote Boot ManagerDownloads.

The Remote Boot Manager requires the images to be stored on that location.

Configuring Remote Boot Manager

The last task to make the image remotely deployable is to configure the Remote Boot Manager to send the image to the clients whenever they request.

1. Take note of the MAC Address (comprised of 12 hex digits) for the computers that will boot remotely. If you are using virtual machines you can easily find out the client NIC’s MAC address by taking a look to the Network Adapter options.

2. Open the Remote Boot Manager, from Start | All Programs | Microsoft Windows Embedded Studio

3. For each diskless computer that will boot remotely, add a new row to the grid, using the following values

a. Type down the MAC Address of the NIC you are configuring

b. Since the Boot Server is the local machine, leave the field at 0.0.0.0

c. As the Boot Program, select the startrom.n12 option. This boot program boots the client computer without asking for confirmation. Since the client computers may not have a keyboard or monitor attached, this is the preferred choice

d. As the Image File Name type the name of the second SDI file. In this case, type ramdisk.sdi

4. Click on Save

Booting client machines

Now that you have set up the DHCP server, created the image and set up the Remote Boot Server, it is time to boot the client machines.

When configuring each client machine, verify that each machine has PXE network booting enabled.

To verify that all of the previous steps were performed correctly, try booting a machine, verifying that it is booting from PXE. After it receives the IP from the DHCP will load the image and the configuration from the Remote Boot Server.

Client receiving image from the server

Client booting the image downloaded

Well that’s pretty much for now with Windows XP Embedded. I’ll be reviewing Windows Embedded Standard 2009 on next posts.

Hope you found it useful.

Cheers

Preparing and Installing Windows XP Embedded Images – Part I: Setting up the Environment

Preparing and Installing Windows XP Embedded Images – Part II: Building Images

Now that the environment is ready as we’ve seen on the first part of these posts, let’s start on creating our own Windows XP Embedded image. There are involved different kinds of tools to accomplish this, but you will see that is a simple process at the end of it.

The big picture of this process is that the images are built on the server; using the hardware data from the clients.

Target Analyzer

This is the tool that you will use to get the hardware data from the clients.

The data represents all the drivers that the Windows XP Embedded image will include to support the hardware on the clients. When Windows XP arrived you probably noticed that a huge difference appears on the hardware detection of the operating system; it’s mainly because the XP included almost every device driver that was available on the market. With Windows XP Embedded the same thing happens, but since you are customizing images for particular clients you must first find out the hardware that it’s available on them.

Using Target Analyzer it’s very simple:

1. First of all you’ll need access to the client’s machine to run this tool. 

If it’s a virtualized environment where the server and clients will be using same type of host (physical machine) then there’s no need to access to a “client machine” because the hardware will be the same as in the server. If that’s the case, on your server just access to the folder:

C:Program FilesWindows Embeddedutilities

If they are not virtual machines and they have completely different hardware, you should copy those folder files to a client machine.

2. Double click on tap.exe (Target Analyzer Pro).

Note: There’s also a simpler version of Target Analyzer available, named ta.exe. This tool only compiles a short list of your hardware, and is more suitable for smaller environments.

3. The tool stored a file with all of the hardware information, named devices.pmq. You will use that file when creating the hardware image.

Using Target Designer

The Target Designer is the main tool to build the images. Here you’ll add all the drivers necessary for your clients, components of Windows XP Embedded, etc.

1. From the Start menu, All Programs, Microsoft Windows Embedded Studio, open Target Designer

2. Create a new profile of the image that you’ll create. To do that, click on File | New. Select a name for your configuration and click OK to close the dialog

3. The first thing to do is to import the hardware data. This way you will have more chances to succeed, avoiding the “missing drivers” problem. From the File menu click on Import

4. Locate the file that was created with Target Analyzer: devices.pmq. That was left on the utilities folder. Click on Open

5. The Import File dialog will open. Click on Start to begin the process

6. After this process finishes, you’ll see on the center pane that all the hardware components were added to your new image.

Using Design Templates

Now that you have the hardware components added, the next step is to add the required XP operating system components.

On the left pane there are thousands of components that can be included to the images. The Design Templates will help you on adding the right components depending on the client machine profile that you are looking for.

Each template was built targeted at a specific scenario.

You can check on the specific data and components included by each template by right-clicking on any template and selecting Component Help.

To add the components within the template to the current image, you can right-click on the component and select Add, or just drag and drop the component to the image component list.

Adding these templates will not automatically add all the components necessary for the XP Embedded image; those components will be added when the Dependency Check is run, which you will use afterwards.

RAM Disk Driver

When creating a Windows XP Embedded image that will boot remotely, you need to add additional drivers. To be able to remotely load a disk image and keep it on RAM, the RAM Disk Driver is needed. This component is the one that is load to support booting an XP Embedded image from RAM memory.

You can add it simply by using the Search option on the left pane of Target Designer. Use the phrase RAM Disk Driver to find the location of the component

To add the component, you can right-click on it and choose Add, or you can drag it to the center pane.

System Cloning

When you are deploying the environment on more than one client, it is a good idea to use the same image on each client, enabling large scale deployment. To be able to share the image, computer-specific information (such as computer name and security identifier) must be removed from the image.

There is a tool named fbreseal (first boot reseal) that removes this computer-specific functionality. This tool is run on the first boot on the newly installed OS, and prepares the computer for deployment on several clients. When the computer is rebooted, the computer will generate a random computer name and SID.

To add the fbreseal tool, locate and add the System Cloning Tool component.

Checking Dependencies

Now that you added all of the components and design templates necessary for your environment, it is time to check that all the components have the right dependencies in place.

This process will add the components that are missing to complete and guarantee the correct functionality of the image.

1. From the Configuration menu, click on Check Dependencies. This process may take a few minutes depending on the amount of components it has to process. When the process finishes, click on Close to continue

2. When you close the dialog, you’ll notice that there are some new items in the lower pane (“Tasks”). These are related to some dependencies that you need to resolve to complete the image.

3. Double click on each of them and you’ll see a menu of options to decide the correct component for each case. Fix each dependency until you fulfill all of the dependencies. Repeat steps 1 to 3 until you get no more dependencies unsatisfied.

These are the most common dependencies to resolve.

a. Regional and Language Options. To be able to boot the OS, you need to choose which language(s) the operating system will support. Simply select the language that you’ll use on the clients and click on OK

b. Advanced Configuration and Power Interface (ACPI). This component requires a boot loader to be specified. In this case, NT Loader is used (EWF NTLDR is used when booting from a read only media, like a CD)

c. Session Manager. To be able to log in, the system requires a Session Manager. Depending on your project, you will use either Minlogon or Windows Logon. Their main difference is that Minlogon is the smallest and logs in the user automatically as System, and Windows Logon takes more space on the image, but allows logging in as different users

d. User Interface Core. This component requires that the system should support a file system format, such as FAT or NTFS. Since NTFS supports permissions and compression, select it

e. Windows Logon (Standard) requires a shell to be specified. For the purposes of this image, just Command Shell is required

Configuring Components

When you are creating a Windows XP Embedded image, some components provide a configuration pane.

Windows Firewall Settings

If you are deploying the XP Embedded Image with applications that require incoming network connections, the Windows Firewall component must be added and turned off. If the Firewall component is not installed, the default action is to reject incoming connections.

This does not affect outgoing network connections.

Building the Image and the First Boot Agent

After you checked that all the dependencies have been fulfilled, the next step is to build the operating system image.

1. From the Configuration menu, click on Build Image

2. Select a folder to store the files to be copied on the image. The default location is C:Windows Embedded Images

3. Click on Build

4. A message will appear saying that it’s recommended to run the dependency check since there were some changes from the last time that it was run. If there were no significant changes that was made that could make any difference on the dependencies, you can choose No. Otherwise choose Yes.

After completing this process you can access to the folder where the files were introduce and check that the operating system files are created.

With that you have an image ready to be used of Windows XP Embedded, please take notice of the size of this image, because if you are planning on having it with a remote boot on diskless devices you’ll need twice amount of RAM or sufficient space on your USB/Flash device.

On the next post, we’ll see how to use this image on a Remote Boot environment with diskless devices.

Cheers!

Preparing and Installing Windows XP Embedded Images – Part I: Setting up the Environment

Preparing and Installing Windows XP Embedded Images – Part III: Using Remote Boot

Embedded operating systems have been present among us since a long time ago. Windows XP Embedded and several others have been a part of tons of devices for various reasons:

- Componentized version of the bigger operating system, with only the components that the user requires.
- Small footprint: Around 40mb at minimum for Windows.
- Secure operating systems; with selected features installed we can reduce at minimum the attack surface.

Payphone working with Xp Embedded.

Microsoft recently released Windows Embedded Standard 2009 that will succeed Windows XP Embedded. This version it’s not actually the embedded version of Windows Vista. That embedded operating system is still in progress (expected for 2010) with the codename “Quebec” that will contain most of the Vista features, like Aero, Bit locker encryption, Windows Defender, etc.

Windows Embedded Standard contains basically the same kernel than XP Embedded with a few improvements: Silverlight, .Net Framework 3.5, Internet Explorer 7, NAP, among other features.

Diskless Operating System

These types of operating system have been designed for special cases and special type of devices (like the one shown on that payphone), most of them that need a “locked-down” operating system, the smaller and secure as possible.

That’s why the design it’s prepared to use this operating system on diskless devices, having a Remote Boot Manager server that contains the client operating system image and the device requires the image from that server and boots it directly from RAM or an USB device. We’ll see how it works.

Enough with the introduction, let’s start with this step-by-step guide for Windows XP Embedded.

You can find the other two parts of this guide, here:

Preparing and Installing Windows XP Embedded Images – Part II: Building Images

Preparing and Installing Windows XP Embedded Images – Part III: Using Remote Boot

Let’s start with the system requirements.

System Requirements

Remote boot server

- Windows Server 2003

o R2 and SP2 are optional but recommended
o DHCP role must be installed

- Windows XP Embedded Studio Tools

o Component Data Base Manager
o Component Designer
o SDI Loader
o Target Designer
o Target Analyzer
o Remote Boot Manager

Hardware Requirements

- Processor: Pentium III 800 MHz (Minimum)

- Memory: 256mb (Minimum)

- Hard Disk: Enough space to store XP Embedded images

Clients

Hardware Requirements

- Processor: Pentium III 800 MHz (Minimum)

- Memory: 512mb/1024mb
It must double the XP Embedded image size, so for 450mb images there should have 1 GB of memory available on the clients

Installing Windows XP Embedded

Installing the Embedded Studio Tools

We are considering using the installation of the Studio Tools with SP1 and then upgrade it SP2. This setup assumes that you are installing the tools in the computer that will act as a Remote Boot Server.

To install Windows XP Embedded SP2 tools, please follow these steps:

1. From the Disk 1 of the installation files, run SETUP.EXE

2. The installation Wizard starts. Select the Tools Setup tab, and click on Next

3. Accept the License Agreement terms, and click on Next.

4. Enter your user name, organization name and your license key number (a trial license number can be obtained from this site). Click on Next

5. On the Installation type select Typical. Click on Next

6. Now you will set the Windows Embedded Server as the local computer. To do this, leave the This Computer option marked and click on Next

Note: You can also change the default folder where the XP Embedded images will be stored when they are built.

7. Click on Install to complete the setup wizard.

After this installation completes, switch back to the Welcome to Windows XP Embedded installation window to install the remaining components.

Installing the Database Engine

To create Windows XP Embedded images, the Designer component requires that a database must be installed and set up. The current version requires that MSDE should be installed the local computer (or a remote computer). This setup assumes that you will install MSDE on a local computer.

1. To set up the database, the first step is to install the database server. To do this, point and click on the Database Engine Setup tab

The database engine will install without requiring user intervention.

2. Let’s install the database. To do this, point and click on the Database Setup tab

3. Click on Next and accept the License Agreement

4. Enter your Product Key and click on Next

5. Select the Typical installation option and click on Next

6. Click on Install to begin the installation. The following message will pop up. Answer Yes

Don’t worry; it just says that to create embedded images, a share folder will be created on the server with read-only permissions.

Upgrading the installation to Windows XP Embedded SP2

To complete the installation, you must access Disk 3 of the installation files and run setup from there. This will upgrade the components and tools to Service Pack 2 and will also install the Remote Boot Server from there.

1. Let’s update the database engine with the latest updates. To do this, point and click on the Database Engine Update tab on the left.

This process does not require user intervention.

2. Now let’s update the Windows XP Embedded Tools to SP2. To do this, point and click on the Tools Update tab on the left.

3. A wizard will pop up. Click on Next to proceed with the installation.

4. Before installing the “Database Update” you must first verify that the Engine is already running on the server. If you don’t reboot the computer after installing the database engine, the service is not yet started. To start it use the services snap-in, following these steps.

a. Click on the Start menu, select Run and type services.msc. Click OK

b. On the services console, locate the MSSQLSERVER service

c. Check that the Startup Type is set to Automatic

d. Check if the service is started. If not, right click on the service and select Start

Note: If the service is not started as it shows and if you try to update the database, this message will appear to you: "Cannot connect to the database – please check the database. Setup cannot continue"

5. Switch back to the installation window. Point and click on the Database Update tab on the left.

6. Before installing the update, a message will prompt with the warning that you should make a backup of the existing database before updating. This is an optional step. To continue, click the OK button.

7. A wizard window will open. Click on Next to continue.

8. The wizard will show the license agreement. Read and accept it, clicking on Install to continue.

The process will take several minutes, depending on your system characteristics. When the installation finishes, a summary will appear, including the modifications it performed on the installation. Click on Finish to close the dialog.

9. [Optional] To set up a development environment you can also use the libraries that are included to test the applications outside the run-time images: Enhance Write Filter API.

Installing the Remote Boot Server

The Remote Boot Server is in charge of providing remote computers the run time image of their OS. In this section you will install the associated component.

1. From the tab list on the left, click on Remote Boot Server.

2. An installation dialog will appear. Click on Next to continue. When the dialog prompts to accept a license agreement, read and accept it.

3. Enter the values in User Name and Organization and click on Next.

4. Select the Typical installation type, click on Next to advance a screen and finally click on Install to start the installation process.

When the process completes, you’ll have your environment ready for preparing Windows XP Embedded images.

Note: Remember that the DHCP server must be up and working on the remote boot server to actually achieve the Remote Boot with the prepared images.

We’ll be reviewing the next steps on two more posts.

Preparing and Installing Windows XP Embedded Images – Part II: Building Images

Preparing and Installing Windows XP Embedded Images – Part III: Using Remote Boot

Cheers!

In case you’re looking for something fresh (and it’s signed by Microsoft, so you won’t need to hack anything to make it work)…

Windows XP users have not really seen a lot of love theme-wise from Microsoft since the release of the operating system. A measly handful of official themes have been released by Microsoft and the trend seems to continue for Windows Vista users. There is not really a reason to not to supply customers with fresh themes for their operating systems. If you look on the Internet you find many resources that cater to the needs of users who want to change the default themes.

Official themes on the other hand have the advantage of being signed meaning that there is no need to tamper with the uxtheme.dll file that protects the operating system from unofficial themes. Vishal over at Ask VG discovered a new signed Windows XP theme that is also compatible with Windows Server 2003 that can be installed without changing system files.

He discovered the theme in the Windows Embedded Standard CTP Refresh distribution and provided download links to it. The theme is supplied as a self extracting executable that installs the theme in the right location in Windows. The theme can then be selected from the Themes tab in the Display Properties.

(via ghacks.net)

A Microsoft lançou um novo tema para Windows XP, é o Windows Embedded theme, que traz um azul escuro em um tema muito bacana seguindo os padrões do Luna.

Na verdade, o tema não é lá tão oficial, parece que extrairam ele do Windows XP Embedded e disponibilizaram para download. Ele é o padrão do sistema, ou seja, oficial. Para usá-lo você não precisa seguir tutoriais como esse.

Para instalar basta abrir o instalador, clicar em Install e aplicar o tema pelas propriedades de vídeo (O wallpaper também está incluso)!

• Download: Windows Embedded Theme
• Sistema: Windows XP, 2003
  
• Via: Guia do PC

Next Version of Windows Mobile 6 , that is Windows Mobile 6.1 should be hitting the market in first quarter 2008.It would have enhancements over winmo 6.

It would have message threading so that you can view all the message in its context (Ala Palm Treo).

Home screen has been redesigned, a new application called Task manager (like Desktop Taskmanager) would be a part of it

it supports bluetooth DUN

support for vCard Version 3.0,photo sharing through bluetooth

while roaming when user wants to make a call a message would be shown to notify him that he is on roaming

it include communicator mobile

better integration of 3GPP codecs with Windows Media Player

Came across this interesting link today. Channel 9 guys have created a wiki for the Wince base port development. I am sure this would be welcomed whole heartedly by whole lot of BSP developers,since there are only a couple of books that I know of of Windows Ce BSP development,and they are quite old.

This should be fun to follow,here is the link:

Big Book of BSP