Domain

Ah... very true. I didn't really think about this, since the early days when I automated the process, I always copy in a fresh wim at the start, and run the entire thing from scratch. It takes awhile, but it can just churn away while I am working on something else. Also in case anyone cares, the only update to my previous lists from above for today's patch release was windows6.1-kb2807986-x64.msu (assuming IE10 is integrated, otherwise there are more) *Edit* I take that back windows6.1-kb2791765-x64.msu also replaced windows6.1-kb2762895-x64.msu

I can't say exactly what the issue is here... there is significant patch overlap once you start integrating IE... I believe you can end up breaking the image by trying to push a patch that was for previous version of IE into an image that already has a newer version integrated. For reference, these are the current set of patches used in my image to bring it fully up to date (at least until patch Tuesday tomorrow): Pre-Req: Critical: Optional:

Hmm, good information, fully tested and working here now. I don't bother with applying every single patch individually, based my testing only order required is to make sure prerequisites are handled first (otherwise it will fail during IE 10 steps), then Internet Explorer 10, then Hyphenation/Spelling, followed by everything else. My base image is now 6 packages (prerequisites), IE 10, 62 critical, and 31 optional updates to get a Windows 7 image requiring no Windows update patches (not counting KB2533552 and Malicious Software Removal Tool) dism /Image:.\mount /Add-Package /PackagePath:.\updates\prereq dism /Image:.\mount /Add-Package /PackagePath:.\updates\ie10\IE-Win7.CAB dism /Image:.\mount /Add-Package /PackagePath:.\updates\ie10\IE-Hyphenation-NEU.MSU dism /Image:.\mount /Add-Package /PackagePath:.\updates\ie10\IE-Spelling-NEU.MSU dism /Image:.\mount /Add-Package /PackagePath:.\updates\crit dism /Image:.\mount /Add-Package /PackagePath:.\updates\opt As for welcome screen/first run, this is working fine (as it has since GA release for IE8/IE9/IE10) <settings pass="specialize"> <component name="Microsoft-Windows-IE-InternetExplorer" processorArchitecture="amd64"> <DisableFirstRunWizard>true</DisableFirstRunWizard> <Home_Page>about:blank</Home_Page> </settings>

I'm a little confused from your description... your saying that applying this during T-12 does not affect the first logged in user? Or are you trying to accomplish something different? "HKU\.DEFAULT" applies to the idle system account, i.e. it is techincally the registry entries used when a user is NOT logged in (at CTRL-ALT-DEL screen, etc.). Also at T-12, i'm not entirely sure what account is being used, so applying to HKCU would only accomplish applying those settings to whatever account Windows is using at that time. If you are on the other hand trying to target the "skeleton" account used to create all new users, then you have to specificially load that as a registry hive and apply the settings there. I'm really unsure how well that would work during T-12 as i've never tried it myself, but in theory it should work.

As to the question about choosing RTM over SP1/SP2, I can see no compelling reason to stick with RTM. The primary reasons I have seen people cite for sticking with RTM generally has to do with DirectX issues, primarily with applications detecting strange DirectX versions as being installed ( i.e. Nvidia drivers report DirectX3, etc. ). Unfortunately the largest majority of posts I have seen regarding the DirectX issue do not seem to understand why this problem occurs, and provide strange methods for resolving it ( i.e. Mixing versions of DirectX 9.0b and 9.0c installation files together to reinstall ). Without going into too much detail, the problem results from the fact that while SP1+ updates Windows 2003's DirectX version, it also removes DirectMusic entirely ( likely for security reasons ). This will cause a number of old applications/games to complain, while others that do no use this functionality will work as intended. The fix is rediculously simple, requiring you to copy the 9 missing DLL's, along with adding a few registry entires, all of which can be taken from either the existing DirectX installers, or from a previously running copy of Windows XP x64 Edition. The only other problems to note with SP1+, is much like Windows XP SP2, the additional features such as DEP, Firewall, etc. can cause some compatibility problems, but there are numerous resources available that describe how to resolve such issues. As for the ideal of using Windows 2003 as a workstation in general, it really depends on what your needs are, but you should be aware that a number of applications ( Defragmenters, Antivirus, etc. ) will only allow you to install "server" versions of the products, and a number of other software installations will refuse to install based on the Windows version. Unless you have some specific need for functionality in Windows 2003, and a large sum of $$$ to pay for a server license, you are unlikely to see a *huge* difference between it and the workstation counterparts.

I ran into the exact same problem after trying an integrated installation of SP2. Unless the deployment documentation has been updated since I last read it, they make no mention of CD2, other then copying it locally. However "<SP2NAME>.exe /integrate:<path to CD2>" will allow you to integrate the SP into the second CD, and then it will not complain on attempted installation.

If I am understanding you correctly, then problem is that HKEY_USERS\.DEFAULT does not do what you think it does. HKEY_USERS\.DEFAULT does not contain the registry settings for the default user profile, it contains (as I understand it) the registry settings for the profile the system uses when no one is currently logged into the system. If you wish to apply settings to user profile that newly created users inherit, you want to apply them to the default user registry hive, which is stored in "<profiles dir>\default user\ntuser.dat", commonly located in "C:\Documents and Settings\Default User\NTUSER.DAT". To do this, you might use a batch file like so: @echo off REG.EXE /LOAD HKU\DefaultHive "C:\Documents and Settings\Default User\NTUSER.DAT" REGEDIT.EXE /s kb.reg REG.EXE /UNLOAD HKU\DefaultHive This will load the default user's registry hive to HKEY_USERS\DefaultHive, allowing you to directly modify the settings and then unload the hive when you are done. Of course, you will have to modify your registry file to accomodate the new registry key's name. ----- Domain

I've searched through the forums, and read nearly every post I could find regarding oobeinfo.ini, but haven't found any definite answers as of yet... Has anyone confirmed that the oobeinfo.ini method works under Windows 2003? The directory structure / files exist, but i'm not entirely sure that it is ever getting called... it certainly hasn't processed my oobeinfo.ini file...at least for the three attempts i've made thus far. I want to use this method to create a single administrative account (of name I can specify)... I don't use the "Administrator" account as it gets renamed to a unrememberable string of of characters by my security policies, not to mention not even I know the password it gets assigned (safer that way ). I also don't really want the "Administrator" profile directory to ever be written in the first place (i.e. so long as an account never logs in, its profile directory will not exist). This was never a problem with Windows XP, since I just leave the "Windows Welcome" screen intact, and create a user from there... I appreciate any replies, ----- Domain