Microsoft: SP2 makes Windows 15 times safer

File this as a follow-up to my talk at MEDC about XP SP2, XPE SP2, and securing your XPE devices – an internal analysis of XP SP2 found machines running it were 15 times less likely to have one of the top twenty malware apps on it than RTM or SP1 desktops. 

Microsoft: SP2 makes Windows 15 times safer

WEPOS is here

It was announced last night – Windows Embedded for Point of Service (WEPOS) is a reality.  Based on XPE SP2, WEPOS is a retail-optimised platform (not my term)… you know, I should talk in my own voice…

WEPOS is an installable OS, like XP, but it’s based on XPE SP2, and it’s designed for POS terminals and other devices used in retail.  It’s not just our POS macro component with a lot of HW support wrapped in an installer – it’s got some extras that the WEPOS team put together to make devices live better in a retail world.  These guys worked hard to get this thing ready and out the door, and I for one am glad to see it come out.

The MS Press article is kinda dry, but the links take you to cool places.

Retail and Hospitality Industries Cash In With Worldwide Availability of Microsoft Windows Embedded for Point of Service

Microsoft security guru: Jot down your passwords

This makes a lot of sense to me – I use variations of the same password on multiple websites, depending on the strength allowed or enforced, but would like to have different passwords in different places.  My solution?  My Pocket PC – I have a password saving app on my Dell Axim that I use to store these passwords (along with other sensitive info).  Protecting the info is the key, and by storing the passwords behind an encryption layer, all I need to do is remember one password to get into it.  My software?  MyCodes Lite, as I can store other info there as well (like CC numbers and other sensitive data), and it’s freeware as well.

Microsoft security guru: Jot down your passwords | CNET News.com

Microsoft hunts web nasties with honey monkeys

Interesting - this is the first I’ve heard of this, and it’s a good follow-up to my talk on securing XPE devices from MEDC last week.  While nothing in this article is specific to XPE, it will bear fruit for XPE device makers as a welcome side-effect of it’s goals of protecting XP desktops.  A variation of a honey pot, the “honeymonkey” concept doesn’t wait for hackers to come feast on the honey, but brings the honey to the hacker looking for exploits.  The use of virtual XP machines is a good approach as well.  Strider is a tool developed by MS to find root-kit viruses, viruses that mask themselves from normal scans by hooking and/or shimming XP binaries.

Microsoft hunts web nasties with honey monkeys | Channel Register

MEDC 2005 Wrap-up

Well, MEDC is over – sorry I didn’t post more last week.  For some reason, when I got back to Seattle Friday afternoon I was very tired – might have been the fact that I averaged 4 hours of sleep per night while in Vegas (go figure).

The last day was pretty cool – I volunteered to referee the SumoBot competition, which was won by the lone RC entry from ASU.  We had some cool prizes, including more bots from Parallax, and the final event was very exciting and even attended by Elvis.  Mike Hall has some cool pod cast videos on his site – I’m looking forward to him posting the one of me and Elvis at the SumoBot competition.

This year’s Devcon was probably my last – if you were there, or have read the blog, you know that I’m no longer on the Embedded team, so my chances of going to future Devcon’s will be low.  Sean Liming will be presenting my material on securing XPE devices at the MEDC roadshow in Europe and Asia – the info will be the same, so if you have a chance to go, I urge you to.

One very cool thing we did was during the keynote, which I reported on earlier – a working HORM demo during Bill’s speech.  I have to give thanks to Brad Combs’ XPEFiles – during the development of that device, we discovered that the video driver was not part of XPE as shipped.  We searched XPEFiles and found the driver componentized there – 10 minutes later, we were rebuilding the runtime with the updated driver and within 30 minutes were seeing an 800x600 32–bit color rather than 640x480 in 16 color mode.  Very cool, and my thanks to Brad for running his site.

In other news, there was a recent report on eWeek about a faulty security update, namely MS05–019 (thanks to Andy Allred for bringing this to my attention).  I haven’t heard anything about XPE customers being affected by any aspect of the faults, but we will be handling the re-release in our next regularly scheduled security update package for XPE.

Day Two begins

You know, I wish I had something to report from this morning, but since I had no commitments until this afternoon, I spend the morning in a small poker tourney (placed 7th out of 30, top five paid).

However, I do have some info from last night’s Ask the Experts session, where I had a chance to talk to more than a few customers.  One thing that came up was using RDP to access a Minlogon XPE box – this cannot be done.  RDP requires a user with a password to authenticate – since Minlogon has no concept of a “user”, you can’t login to an XPE box based on Minlogon using RDP.  Also, the default RDP behaviour of only having one active session on XP Pro carries to XPE – you can’t have someone logged into the XPE machine directly and someone logged in remotely, and have them both working at the same time.  You’ll need to go with NetMeeting or some other alternative to provide for two people to access the machine simultaneously.

Look for more later…

Sweet! XPE demo goes off well

Mike Hall just got through with a demo of the new Windows Mobile 5.0 – part of the demo included an XPE SP2 device with HORM.  On stage, Mike pulled the plug on the device, then plugged it back in, and watched the device POST and reboot into the custom shell with about a 7 second delay. Sweet!

If you missed the streaming keynote, you should be able to get it on demand from the webcasts site.

MEDC - Day One Continued

Well, the first post that was supposed to go out this morning took a while – seems my blog posting software, BlogJet, was configured to use the internal MS proxy server rather than auto-detecting (which explains a lot).

Now it’s around 5pm – I’m running through my hands-on lab (HOL) to make sure it will work as advertised and get the kinks out of it.  After this is done (probably another 30 minutes or so – it’s going through FBA now), and I’m back up in the room to get ready for the MVP dinner.  We’ve invited 50–60 MVP’s and are going to put them in a room with a few MS folks, some food, and sharp knives – should be fun.

Today’s been a dead day other than prep work – tomorrow should be much more interesting, as that’s when the sessions and HOL’s start in earnest.

Oh, and one quick update – a few customers have reported to us that a feature update we put out last year to add Remote Desktop Protocol 5.2 to XPE SP1 was lost in XPE SP2.  I think I’ve reported on this in the past – indeed, SP2 didn’t include RDP 5.2, so we wound up updating XPE SP2 with RDP 5.1.  In any case, the RDP 5.2 component feature update for XPE SP2 is currently in test – reports are good so far, no major issues.  In fact, the biggest problem is that I forgot to give them the additional info document.  We should have this through component testing this week.

Later…

MEDC Day One

Well, I’m here in sunny Lost Wages.  I always have problems sleeping when I travel, so I was out walking the casino floor around midnight and ordering dinner at 1am.  The thing I love about Las Vegas is that, if you don’t have a watch, you really have no idea what time it is – the casino is open and running 24/7, and the only way to tell time is either by the restaurant closings or the kids walking outside the casino floor.

Anyway, it’s early on Day One (9am to be precise), and I’ve registered, gotten into the speaker lounge and been checking e-mail.  Bumped in to Mike Hall, who will be podcasting the whole time – minor setback when the podcast hardware room was burglarized, but we had the CSI crew in and should have the culprit in 40–50 minutes, depending on whether we’re the main or the sub plot.

Signed in and got my speaker gift – a USB key and a USB set of speakers (think they’re sending a message?  Next year, will it be Bluetooth stuff?).  Had some coffee in my new coffee mug, which was in the backpack they handed out, and some breakfast which was in the speaker room.  You know, I think I’ve figured out why these things are so bloody expensive…

More later…

April component updates available, and Q&A

Updates update

Well, the April updates were posted to the OEM Secure Site last week – the date is April 29, which is right on for when they asked me to verify the bits downloads.  This time gap between desktop updates and component updates will be consistent through the early summer, but expect it to decrease as summer languishes into fall – that’s when we’ll have things in place to start to turn up the heat on getting updates through a more aggressive process.

BTW, you can learn more about the existing process, the new process, and our goals next week at MEDC in Las Vegas.  I’ve got one scheduled session and a hands-on lab about securing XPE devices, and part of those appearances includes some discussion about security updates and the processes around them.  The organisers of MEDC have done something cool this year – in previous conferences, there’s usually a crowd of people surrounding the speaker and the podium, asking questions and engaging in discussions.  Problem is, with a dozen of more people crowding the speaker on the podium, it’s tough to get the next speaker and his audience into the room.  Therefore, the organisers have come up with the idea of a Speaker Cabana – basically, it’s a place somewhere away from the podium and presentation room where we can all get comfortable and have our conversations, which allows the setup for the next guy to take place.  Since it’s a cabana (and it is Vegas), I’m expecting comfy chairs, a drink cart, and some finger food, but I’m ready to accept just a comfy chair and a plug to charge my laptop.  I’ll bring my own potables…  :-) 

Q & A

Now, some Q&A – a loyal (I hope) reader has fired some questions to me directly regarding BootPrep and the vagaries of a dual boot with XP Pro and XPE.  I’ll group the questions together to answer them.

Can you please tell me that what it bootprep utility and why it's used?

BootPrep is a utility we shipped with XPE to allow you to create an XP boot sector on a drive that normally wouldn’t have one, such as a FAT/FAT32 partition.  You only need to run it if the partition you will be booting from is FAT or FAT32 and does not currently have an XP boot sector on it.  To put it another way, if you’re booting from an NTFS partition, or if you’re dual-booting a system that already has XP booting on it, you do not need to run BootPrep – all NTFS volumes have the proper XP boot sector code in them, and a system already booting XP has already been properly setup to boot XPE no matter which volume it’s on.  BootPrep is only useful for making a single drive/single partition FAT/FAT32 system bootable to XPE.

Is it necessary to run FBA on target device hard drive which is formatted by FAT/FAT 32?

It's necessary to run FBA on every system, no matter the underlying file system.

What are ARC paths?

That's best handled by giving you some links to info on the base OS.  Knowledge Base article 102873 has some good basic information on ARC paths.

 And What is GenDisk?

GenDisk stands for Generic Disk, and is a fallback PnP ID for an IDE or SCSI disk.  Basically, any disk that can be used in a PC supports some basic functionality – GenDisk encapsulates that functionality, so that if XP/XPE can’t find a specific driver for your drive, it can still boot from it and read and write data to it.  Some of the links returned by a search on MSDN can give you more info on GenDisk, why it appears, and why it’s useful.

When I do dual boot, I do it on drive D of target device, which is formatted by NTFS system. My root drive is C with XP pro, does this thing giving me problem for RAM boot?

It might - a Remote Boot into a RAM disk presumes that the RAM disk will be C:.  If you are preparing the system on D: so it runs properly, it probably won’t run properly in a RAM disk called C:.  You may want to swap how you dual boot the system – repartition and install XP Pro on D:, then put your XPE image on C:.