I'm trying to be neither alliterative nor redundant - the title just came out that way...
Anyway, back on November 2, I noted that we were working on getting the October updates re-released as EXE and RTF files, rather than CD ISO format. Well, the web development team has the correct bits now and is working to rebuild the pages - I expect the job to be completed by early next week. Look for an update here once the job is done.
There was also a single update released earlier this week that applies to XPE - MS05-053 is a critical security update for XP Pro. We're releasing it as a desktop update and I expect it to be available early next week as well for Embedded customers. The componentized version will be in our next scheduled release in December.
That's about it for now.
Thursday, November 10, 2005
Thursday, November 03, 2005
Ford squeezes an office into a truck | CNET News.com
While I'm normally excited to see technology spread into new areas, this one has me shuddering. You see, I ride a motorcycle ('96 Harley Davidson Wide Glide, in case you were interested), every day to and from work, rain or shine, day or night, hot or cold. I already have a tough enough time dealing with yuppies in BMW's talking on their cell phones on the highways and byways - now I'll have to deal with bubbas in F-350 duallies trying to make stock trades in the HOV lanes.
Add to that the fact they're using XP Pro rather than XP Embedded... Come on, guys! XPE was made for this application!
Ford squeezes an office into a truck | CNET News.com
Add to that the fact they're using XP Pro rather than XP Embedded... Come on, guys! XPE was made for this application!
Ford squeezes an office into a truck | CNET News.com
Wednesday, November 02, 2005
October Component updates - almost
If you've gone to the OEM Secure Site to scan for the October componentized updates, you've been both happy and confused. Happy because the releases are out there - confused because they're in a strange format.
When the bits were released, they were released on CD - this means a few things. First, you can order an October XPE Update CD (that's probably not the name, but that's the spirit of the name) from your AR (whoever you got your toolkit from). Second, we can use existing release processes and teams to do the release, rather than me doing 90% of the release work. Third, because this is a new process, there are teething pains we're working out. The IMG file is one of them.
The IMG format is just an ISO copy of the CD we released. If you have a CD burner and software that can recognize the IMG format, you can burn your own CD - pop that CD into your development machine and you can run the update packages from it, scan the documentation, and archive it for posterity. If you don't have a CD burner and software to support it...
We've recognized this as a mistake, and are working to correct it now. However, rather than pull the release down and put it back up once we get the downloads fixed, we're leaving the IMG file available for download until we get the standard EXE/RTF downloads available.
Like I said, these are teething pains - big ugly teething pains. There are changes to our entire release process, from how I hand the bits off to how the web team handles them to exactly who the people doing the work are. We are making sure this won't happen again next time, but I can empathize with those of you affected by the problems we're having this time.
When the bits were released, they were released on CD - this means a few things. First, you can order an October XPE Update CD (that's probably not the name, but that's the spirit of the name) from your AR (whoever you got your toolkit from). Second, we can use existing release processes and teams to do the release, rather than me doing 90% of the release work. Third, because this is a new process, there are teething pains we're working out. The IMG file is one of them.
The IMG format is just an ISO copy of the CD we released. If you have a CD burner and software that can recognize the IMG format, you can burn your own CD - pop that CD into your development machine and you can run the update packages from it, scan the documentation, and archive it for posterity. If you don't have a CD burner and software to support it...
We've recognized this as a mistake, and are working to correct it now. However, rather than pull the release down and put it back up once we get the downloads fixed, we're leaving the IMG file available for download until we get the standard EXE/RTF downloads available.
Like I said, these are teething pains - big ugly teething pains. There are changes to our entire release process, from how I hand the bits off to how the web team handles them to exactly who the people doing the work are. We are making sure this won't happen again next time, but I can empathize with those of you affected by the problems we're having this time.
Wednesday, October 26, 2005
Possible problem with MS05-052
PSS has found a potential problem with XPE SP1 and SP2 systems after MS05-052 has been added to them using the Desktop QFE Installer versions of the updates. The issue is that ActiveX controls may not activate properly. If you experience this problem, add the following registry keys to your runtime:
Note that you can cut and paste the above snippet into a .REG file and apply it using RegEdit, if it's on your runtime. If not, you can add the keys offline, or using a script.
Also note that you may see this problem with the componentized version - the registry keys are owned by the COM Base component, but I'll do some more investigation and see if I can't resolve this in the components for December.
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{0000031A-0000-0000-C000-000000000046}]
@="ClassMoniker"
[HKEY_CLASSES_ROOT\CLSID\{0000031A-0000-0000-C000-000000000046}\InprocServer32]
@="ole32.dll"
[HKEY_CLASSES_ROOT\CLSID\{0000031A-0000-0000-C000-000000000046}\ProgID]
@="clsid"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\CLSID]
@="{0000031A-0000-0000-C000-000000000046}"
Note that you can cut and paste the above snippet into a .REG file and apply it using RegEdit, if it's on your runtime. If not, you can add the keys offline, or using a script.
Also note that you may see this problem with the componentized version - the registry keys are owned by the COM Base component, but I'll do some more investigation and see if I can't resolve this in the components for December.
Tuesday, October 25, 2005
Running XPE on multiple SQL Instances
There's a great post on the Embedded Team blog that stems from some work we've been doing in Windows Servicibility. My test lead, Randy, came up with this technique in a day - another day to clean it up and make it readable, and you have the post Lynda submitted. What is it?
Well, it's how you can run two XPE databases on the same server, like maybe an SP1 DB along with an SP2 DB, all on one machine. No more second servers to handle the SP2 upgrade.
Why did we come up with this? Simple - automation. I've been talking a bit in this blog, and to MVP's and other customers at events, that moving security work into WinSE meant we had to automate a lot of stuff. One of the first things we automated was the creation of update packages, and the WinSE Build lab is integrating that automation into their normal build processes.
The problem came when they realized they needed to XPE DB's to do the XPE update builds, one for SP1 and SP2. They were really agitated when I told them that, if there's an SP3, they'd need a third server for it as well. They needed a way to use only one server if possible.
SQL Server supports multiple instances - basically, other DB servers running as separate processes on the machine. But CMI was never written to handle multiple instances - it just connects to the default instance on a given machine. The server to connect to is just a single string - no extra setting for which instance to use. But SQL already provides a syntax for selecting a server and specific instance - it's/. If you set that as the DB to connect to in DB Manager, CMI happily connects to the specified instance.
A few things to note about the steps Lynda provides:
Well, it's how you can run two XPE databases on the same server, like maybe an SP1 DB along with an SP2 DB, all on one machine. No more second servers to handle the SP2 upgrade.
Why did we come up with this? Simple - automation. I've been talking a bit in this blog, and to MVP's and other customers at events, that moving security work into WinSE meant we had to automate a lot of stuff. One of the first things we automated was the creation of update packages, and the WinSE Build lab is integrating that automation into their normal build processes.
The problem came when they realized they needed to XPE DB's to do the XPE update builds, one for SP1 and SP2. They were really agitated when I told them that, if there's an SP3, they'd need a third server for it as well. They needed a way to use only one server if possible.
SQL Server supports multiple instances - basically, other DB servers running as separate processes on the machine. But CMI was never written to handle multiple instances - it just connects to the default instance on a given machine. The server to connect to is just a single string - no extra setting for which instance to use. But SQL already provides a syntax for selecting a server and specific instance - it's
A few things to note about the steps Lynda provides:
- We developed these steps for the WinSE Build Lab, which has a SQL Server installation being used for other purposes. Therefore, we added two new instances, one for SP1 and one for SP2, so their default instance wouldn't be affected by XPE. In your setup, you may not need to be so diligent and be able to use just a single additional instance.
- In our build environment, it's important we keep our repository files separated, so step 6 is necessary. You may not need to do this - repository separation is provided in the DB's themselves, and all the update files go into separate repositories, so this may not be necessary. It does duplicate a few Gb of data, so if you're tight on space on your server, you should be able to skip this without affecting your builds.
- Step 5 has you copying databases from one instance to another - we did not test, and do not yet know, if you can install the DB directly to a given instance. If anyone tries this, let us know how it worked.
That's it - questions on this procedure should be sent on a comments to either this post or the original.
Thursday, October 20, 2005
October Updates, and news
Well, part of the October updates are on the OEM Secure Site - the ones for use with the (inaccurately named) Desktop QFE Installer Tool have been posted. I'm looking into why the component updates aren't there - they were actually released by me the day after the desktop updates.
A few notes about these persistent delays - in the past, the delays have been due to engineering delays. We wait until the second Tuesday (when the Pro updates are public) to start our componentization process. Now, however, we're actually done with the componentization and testing a week before everything is ready for release - that week gives us time to actually do the release of the componentized updates. The release process has changed as well - we're releasing via CD direct to the Authorized Resellers, so you can actually order the update CD from the company from which you get your XPE tools and device licenses. Everything up to the burning of the CD I have some control over - after the CD is burned, it's a black box to me.
So, while from my POV we're simultaneously releasing Embedded updates with the Pro updates, the process of getting them onto the OEM Secure Site is still a time consuming process, and means that you still see a week delay. I'm doing everything I can to decrease that time to be as small as possible.
One other note - October included an update for DirectX 9 for both SP1 and SP2(MS05-050, KB904706). XPE SP1 did not ship with DX9, so there won't be a componentized version of the DX9 update for XPE SP1 in the package that gets released. We did ship a DX9 component for XPE SP1 as a separate feature update - I plan to have an update for that feature in December. It will be setup so it won't install on your XPE SP1 DB unless you have the DX9 feature added - let me know if this is important to you by commenting here.
And one final note - you'll want to keep visiting both this blog and the Embedded Team blog in the coming weeks. We're working on something pretty cool that we should have figured out years ago, and I think you'll want to see it.
A few notes about these persistent delays - in the past, the delays have been due to engineering delays. We wait until the second Tuesday (when the Pro updates are public) to start our componentization process. Now, however, we're actually done with the componentization and testing a week before everything is ready for release - that week gives us time to actually do the release of the componentized updates. The release process has changed as well - we're releasing via CD direct to the Authorized Resellers, so you can actually order the update CD from the company from which you get your XPE tools and device licenses. Everything up to the burning of the CD I have some control over - after the CD is burned, it's a black box to me.
So, while from my POV we're simultaneously releasing Embedded updates with the Pro updates, the process of getting them onto the OEM Secure Site is still a time consuming process, and means that you still see a week delay. I'm doing everything I can to decrease that time to be as small as possible.
One other note - October included an update for DirectX 9 for both SP1 and SP2(MS05-050, KB904706). XPE SP1 did not ship with DX9, so there won't be a componentized version of the DX9 update for XPE SP1 in the package that gets released. We did ship a DX9 component for XPE SP1 as a separate feature update - I plan to have an update for that feature in December. It will be setup so it won't install on your XPE SP1 DB unless you have the DX9 feature added - let me know if this is important to you by commenting here.
And one final note - you'll want to keep visiting both this blog and the Embedded Team blog in the coming weeks. We're working on something pretty cool that we should have figured out years ago, and I think you'll want to see it.
Tuesday, October 18, 2005
Format change
Sorry to have to do this, but I'm getting tons of comment spam - at least 10 a day, from all my blogs. Since I blog on Blogger, they have a way to defeat it - code word verification. Simply put, if you want to comment, you have translate the modified bitmap phrase into typed text. Since automated systems can't do this, I don't get comment spam from them.
It's a hassle for you, but to be honest, I really don't need real estate advice from someone who thinks my blog is "really cool", "has tons of great info", and "will definitely bookmark your blog!"
It's a hassle for you, but to be honest, I really don't need real estate advice from someone who thinks my blog is "really cool", "has tons of great info", and "will definitely bookmark your blog!"
Hi, remember me? Been a LONG while since I've posted anything, I know (like July). No good news to report until now...
Seems like Sean Liming's kept himself busy - head up to his Tools page, and towards the bottom, you'll see a link to a new tool called SLDDiff. For those of you who have his latest XPE book, the Windows XP Embedded Supplemental Toolkit, this will look familiar - it's a lot like SLXDiff, but it compares SLD's.
I'll confess that I was the impetus here - I was looking for a way to find differences in 30+Mb SLD's (like our monthly rollup SLD's) and had nothing. I hacked together an XSLT that would pull the pertinent data out of the SLD, sort it, and dump it to a text file. Do that on two different SLD's, then run the text file output through WinDiff (or suitable differencing engine), and you've got a really terrible way to figure out what changed. Sean took that idea, wrapped it in a neat interface, and came up with a tool I use when necessary.
As for the latest set updates, they're on their way - the desktop versions should be on the OEM Secure Site RSN (Real Soon Now), and the component updates are on their way as well. The only thing that you won't find in the component updates is the DX9 update for XPE SP1. XPE SP1 shipped with DX 8 - we do have a DX9 component for XPE SP1, but since I didn't have that installed when I ran the updates, I didn't pick it up. It will be out in November.
One other piece of good news is that we're now using an automated tool for generating updates for XPE - it does everything we used to do over 1-2 days in about 15 minutes, integrates into the existing build process for XP Pro updates, and cuts down on our test time. We're not pushing so hard anymore to get fixes developed and tested, and can take some time to implement more test automation as well. Our hope is to code ourselves out of jobs, but not until we speed up the release process... :-)
Seems like Sean Liming's kept himself busy - head up to his Tools page, and towards the bottom, you'll see a link to a new tool called SLDDiff. For those of you who have his latest XPE book, the Windows XP Embedded Supplemental Toolkit, this will look familiar - it's a lot like SLXDiff, but it compares SLD's.
I'll confess that I was the impetus here - I was looking for a way to find differences in 30+Mb SLD's (like our monthly rollup SLD's) and had nothing. I hacked together an XSLT that would pull the pertinent data out of the SLD, sort it, and dump it to a text file. Do that on two different SLD's, then run the text file output through WinDiff (or suitable differencing engine), and you've got a really terrible way to figure out what changed. Sean took that idea, wrapped it in a neat interface, and came up with a tool I use when necessary.
As for the latest set updates, they're on their way - the desktop versions should be on the OEM Secure Site RSN (Real Soon Now), and the component updates are on their way as well. The only thing that you won't find in the component updates is the DX9 update for XPE SP1. XPE SP1 shipped with DX 8 - we do have a DX9 component for XPE SP1, but since I didn't have that installed when I ran the updates, I didn't pick it up. It will be out in November.
One other piece of good news is that we're now using an automated tool for generating updates for XPE - it does everything we used to do over 1-2 days in about 15 minutes, integrates into the existing build process for XP Pro updates, and cuts down on our test time. We're not pushing so hard anymore to get fixes developed and tested, and can take some time to implement more test automation as well. Our hope is to code ourselves out of jobs, but not until we speed up the release process... :-)
Friday, July 08, 2005
Time to infection - 12 minutes
A story on CRN tells the grim tale of the lifespan of an unprotected machine - according to information from Sophos, a machine on the Internet averages 12 minutes before it’s infected with a worm. The Internet Storm Center estimates the time at 34 minutes, while an AvanteGarde study over two weeks calculated an average 4 minutes before an XP SP1 machine was compromised by bots. Take it as you will – even being very conservative, 34 minutes to infection is unacceptable. If your machines and XPE devices aren’t protected with a firewall and some good anti-virus software, you’re in for trouble.
Tuesday, July 05, 2005
Microsoft Turns Off SUS Downloads
If you’re using SUS on an older XPE deployment, take note here – SUS 1.0 (which shipped with XPE SP1) is no longer available for download from Microsoft. The Windows Update Services component in XPE SP2 supersedes it, and support for the old version ends in one year. Remember, folks, I didn’t make this decision, I’m just reporting the news here…
Oh, and expect the June security update rollups for the XPE DB to be out soon – they just got through test, and need to go through codesigning and release. With Monday being a holiday in the States, I can’t guarantee Friday, but I will push it as hard as I can.
Microsoft Turns Off SUS Downloads
Subscribe to:
Posts (Atom)
