Sygate press release

From Sygate:

Sygate Technologies introduced today version 4.0 of Sygate Security Agent for Windows XP Embedded, expanding its market leadership position by offering the most advanced security solution for Microsoft Windows XP Embedded devices. In addition to enhanced virus protection and anti-application hijacking, other key enhancements increase performance and manageability of the solution. These include a dramatically reduced, single-agent footprint, seamless integration with Microsoft’s Target Designer and the availability of a run-time version of the agent. Sygate Security Agent 4.0 for Windows XP Embedded is the second in a series of releases that began in May. Sygate will continue to roll out new releases in an aggressive strategy to protect solutions built on Windows XP Embedded. Sygate Security Agent 4.0 for Windows XP Embedded will be available to OEM vendors, financial institutions, major retailers and other end-user customers deploying Windows XP Embedded devices, by September 30, 2004.

Read the whole thing here.

WE-DIG Inaugural Meeting Summary

The first meeting of the Windows Embedded Developer's Interest Group (WE-DIG) was last Wednesday evening.  I would have posted a summary sooner, but shortly after the meeting, I was on vacation...

Anyway, the first meeting was focussed on Windows CE 5.0 - not exactly prime subject material for this blog.   We had Mark Miller (CE Architect) and Chip Schnarel (CE Group Program Manager) available for a Q&A session at the start of the meeting.  They were able to answer a lot of questions from the floor as well as some scripted interview questions.

The second half of the meeting was broken into a few sections.  First, we had some show and tell of some cool embedded devices (all CE based, I'm afraid), and some cool tools from Entrek.  We also had an open Q&A session where people brought up problems that had been plaguing them and we brainstormed some possible solutions.

At the very end (and here's the reason to show up if you're in Seattle) we had a drawing for some cool prizes.  The featured giveaways here were an HP 2210 iPaq and a Motorola 220 Smartphone, but there were t-shirts, hats, and some books being given away as well.  The meeting ran long, but there was pizza half way through, so it wasn't too bad.

Next months focus is on XPE, and if you're in Seattle, stop by - we'll be talking about XPE SP2, showing off some demos and hopefully making announcements about availability (hopefully).

Some info on SDI and Remote Boot

I've been doing some work for a customer or two involving Remote Boot Services (RBS) and SDI, and have found a few things of interest.

First, SDIMGR.WSF does run under XPE runtimes.  As with most everything XPE-related, however, there are a few caveats:

• You need to add SDIMGR.WSF and SDIAUT.DLL to the runtime (either manually or in a custom component you create - we don't have an SDI component).
• You need to register SDIAUT.DLL before proceeding (manually on the runtime using regsvr32, or as an FBA resource in a custom component).
• The runtime has to have the Windows Script Engines component in it (this is a "duh" info point).
• The runtime has to have the Primitive: Mlang component in it (this was new, and has been bugged).

Second, you can use RBS and SDIMGR.WSF as a deployment mechanism.  Basically, this involved remote booting your device with the media you intend to ship in the device (use the workaround posted earlier), then use SDIMGR.WSF to write the image you wish to ship onto that media.  Note that this means you need two SDI images - one to Remote Boot from, and one to write to the underlying media.  There are some things to be careful of:

• If you use /WRITEDISK, the size of the disk you created the deployment image from will be reflected on the shipping media.  For example, if you created the SDI from a 128Mb flash drive using /READDISK, you will have a 128Mb partition on whatever flash you deploy to, even if it's much larger.  The rest of the space will be unused.
• If you use /WRITEPART to overwrite an existing partition, there will be a disconnect between the partition table and the BIOS parameter block (BPB).  Because /WRITEPART doesn't overwrite the partition table, it will still have the original partition size, but the BPB will have the partition size from the SDI file.  Using the above example, if you use /READPART to create a 192Mb SDI, then use /WRITEPART to write it over an existing 256Mb partition, you should still have a 256Mb partition when you're done.  This doesn't seem to affect the runtime, although CHKDSK may complain about it.  To be honest, I haven't tested it yet.

That's about it, although there is one benefit that is strictly personal.  By engaging in these recent RBS issues, I reconfigured the test machines in my office a little - I now have a private network with a Win2K3 server acting as my remote boot server, one machine acting as a gateway straddling the private and corporate networks, and have trashed an older test machine and replaced it with a better one from the lab (actually, it's an XBox Development Kit machine).  In short, I'm in a much better testing position than I was a month ago, and even have a private network to play around with - no more explaining to our IT department why I need rogue DHCP server on the corporate net!

Building Servicable Devices

There's a new whitepaper on MSDN that I've authored called Building Servicable Devices.  It's been in the works for a while - I wrote the bulk of it a few months back, but then ran out of bandwidth with all the XPE SP2 work I was doing.  By the time someone got traction on it, it was July.

Anyway, the paper is there and covers some high level topics on how to think about servicing XPE devices.  There are links to key Windows technologies that can help, and there's talk that a more in depth paper is coming as well - more on that as it happens.

Let me know if any reads the whitepaper (or this blog for that matter).

Remote Boot deployment issues

I've been working on an issue for two different customers who are trying to use Remote Boot Server (RBS) as a deployment tool.  The scenario goes like this - build a remote boot image, boot a device using that RBS image, then copy a different image from your network to the underlying media on the device.  The steps for building the RBS SDI include booting the device through FBA, then cloning the image using FBReseal.  After the cloning, you build an SDI from that golden master image to capture the image ready for remote booting.

The problem occurs when the media you built the RBS SDI on differs from the underlying media now in the machine.  For example, if you built the RBS SDI on a 256 Mb flash card, but the device you're booting now has a 128Mb flash card, you cannot see or access the 128Mb flash.  This is a known issue for us - we have a bug on it.

The good news is there is a workaround for this issue (which is 99% of the way to resolving the issue for one customer).  Creating the RBS SDI is a two step process - copy the golden master image to a partition in an SDI file, then read that partition into a second SDI file that becomes the remote boot image.  Before you create that final SDI, but after the image has been cloned, you need to delete the following registry key:

HKLM\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\gendisk

This key is created during FBA and is tied to the underlying media.  Because the media is changing between the time of cloning and the time of booting, there is no longer a connection between the two, so if the media changes, the connection is lost and you can't see the media anymore.  By removing this registry key, PnP will detect the underlying media, recreate the key, and make the link between the two.  Viola!  Now you can see the underlying media (usually as drive D:, since the RAM disk is drive C:).

No need to thank me - that's what I'm here for.  Well, that and the free soda...

Inaugural WE-DIG meeting date set

I just joined the Windows Embedded Developer Interest Group (WE-DIG), based here in Seattle for now.  It's a group of embedded developers who use Microsoft technology - that includes Windows CE, Mobile, and of course, XPE.  Our first meeting is set for September 1, 6:30pm-9:00pm, on Microsoft campus - if you find yourself in Seattle around that time, drop me an e-mail and I'll give you directions and make sure you can get in.  The meetings are open to all embedded developers, not just MS employees - in fact, the group was spearheaded and is being led by Paul Yao, an eMVP who focuses on CE development.

I'd also encourage everyone, even if you can't get to Seattle for the meetings (first Wednesday of every month, same time), to go to the WE-DIG web site and sign up.  We've got plans for original content, a wiki for everyone to contribute to, and regular news items.  Everything's RSS enabled as well, so once you've signed up, you can keep up to date in your favorite RSS reader.

There are plans to expand WE-DIG to other cities - we've got some people interested in setting it up in other locations as we speak (or as we type and read, whatever).  We want to see how this works in Seattle right now, then we franchise.

NIST document on securing Windows XP

Last week, I found an interesting document from the NIST (National Institute os Standards and Technology) titled Guidance for Securing Microsoft Windows XP for IT Professionals: A NIST Configuration Checklist (PDF version).  It's an interesting read - they cover a lot of ground, and it is aimed at XP Pro boxes living used in business environments (they do cover small home-based business PC's as well as large enterprise installations, so it's fairly wide ranging).

A while ago, I remember working on a document that gave XPE specific commentary on some whitepapers that covered XP Pro.  The whitepapers came from MS, and the document I provided was fairly light - it said, here's the doc on XP Pro, and here's how this works on XPE (unfortunately, the doc isn't on our web site, but there is a collection of security documents available).  So in that spirit, I want to write a similar XPE based document that covers some of the NIST recommendations.  I'll be pitching the doc to the team later this month, but I wanted to list some of my thoughts here.

First, the document covers XP Pro SP1, and doesn't cover SP2 security features in the main document (it does cover them in Appendix B, but covers the Beta version).

Second, since the NIST doc is aimed at IT pros managing XP Pro systems in an enterprise environment, some of the security recommendations won't fly depending on your device environment.  Stuff like Active Directory, group policies, automatic updates, and account policies are a "use 'em if you got 'em" proposition for most embedded developers.

Third, because the doc is aimed at securing Pro devices, most of the recommendations cover how to change settings in the UI.  One of the challenges I'm going to have is mapping the UI they provide to component settings or registry keys you can tweak.

Lastly, the document is very complete - it 147 pages of tight text and specific recommendations.  While I'm not a fan of government documents in general, this one is fairly well done - I don't think it would be much lighter had it come as a single document from us.

I like this document - it covers a lot of ground, doesn't waste a lot of time, and brings together a bunch of key security concepts along with some practical advice as well as samples.  If you haven't read it yet, get it and read it.  And if you have to print it, go with double-sided four pages per sheet - it is long.

Brad Coombs webcast on Wednesday

July 14, 11:00am PDT, you'll want to go to the MSDN Webcast site for a webcast by Embedded MVP Brad Coombs (host and owner of XPE Files) for a talk on Windows XP Embedded.  I'll be there listening to him, and you should be too, especially if you're not quite sure if XPE is right for you.

Testing BlogJet

I have installed an interesting application - BlogJet. It's a cool Windows client for my blog tool (as well as for other tools). Get your copy here: http://blogjet.com

"Computers are useless. They can only give you answers." -- Pablo Picasso

Goodbye to Devcon

Well Devcon is almost over - it's the last day of the conference, and not much is happening. I was able to review my speaker stats for the two labs and the session I gave - not bad, all around a 7 of out of 9 rating. The docs for these labs and sessions will be available at some point in the future - as soon as I know where they are, I'll let everyone know.

All in all, it was a good show. I was pleased that my labs and sessions went well. I was even more pleased when I winged in an addition to the SP2 lab, adding a Bluetooth demo to the lab on the fly - it worked flawlessly. I like Bluetooth, and will be buying myself some Bluetooth HID devices in the near future (soon as I can find a BT Natural keyboard).

I was able to attend a couple of other labs and sessions as well - Joe Morris' lab on patch management went over well, and Sean Liming's labs drew big crowds and delivered. We went to dinner last night and by the time we got back to the hotel, the big Beach Bash party was already over (well, not over, but they were closing the bar, so it was coughing up blood). We headed back to the Gaslight district and hit a dance bar, but I called it an early night - I'm way too old to be dancing like that. I'll try to post some pics of the conference and San Diego over the weekend - got some pics of the MS crew here, as well as some of our MVP's (Mr. Vorchak looks a lot scarier in person than he does in the pictures...)