baliktad

What you want is a basic text file search and replace utility. You may find rep.exe somewhere on the net. A better bet would be a Win32 port of gsar (general search and replace), which is part of the gnu utility set. You can get a set of Win32 unix utils here. Quite useful really, and free. You'll have to work out the syntax to do what you want.

One more update for the SP1 glut: Business Contact Manager. Microsoft refers to this software add-on as "Outlook 2003 with Business Contact Manager" so the first service pack is named "Outlook 2003 with Business Contact Manager Service Pack 1." Despite the semi-misleading title, the service pack is for BCM (which can only be installed on top of Outlook 2003) and not Outlook by itself. KB 839881 has a description, or just download the Full-file update directly (~1.5 MB).

The OPK.chm (and ref.chm for that matter) Aaron posted above are identical to those included in the official SP2 RC2 OPK (build 2149). One additional file is included on the OPK cd, namely winpe.chm. This file, if present in the same directory as OPK.chm, will show up as another reference "book" in the TOC just like "Reference" does if you have ref.chm present. Winpe.chm details Windows PE 2004, new for Windows XP SP2. We'll have a much better chance of obtaining this file when SP2 ships.

Microsoft cares very much when people start duplicating CD's to sell. If they catch you doing it behind their back, they will pursue legal action. Basically there are 2 ways to sell Windows licenses: 1) As a Royalty OEM. These are large systems integrators like Dell, HP, Gateway, etc that sell tens of thousands of PC's. Benefits of being a royalty OEM include: permission to duplicate Windows CD's with your own customizations, the ability to get your bios strings signed by Microsoft so your systems can use SLP instead of being activated, and permission to distribute "recovery media" (OS images) instead of an actual Windows CD. 2) As a System Builder. This is the little guy buying as few as 3 OEM copies of Windows at a time. The rules are much more strict here. The system builder MUST give the customer the original hologrammed OEM Windows CD and is prohibited from duplicating CD's to distribute to customers. They can optionally include a hard-drive based recovery system (hidden partition with OS image) but cannot make a copy of said recovery solution to removable media. If you are interested in selling Windows, you can sell full retail product (boxed and shrink-wrapped) just like Staples, etc. do, or you can sell OEM copies as a system builder with hardware. Microsoft does not provide support for OEM copies, hence the reduced price point.

I used the method detailed in the Windows 2003 OPK for integrating bootable mass storage device drivers. Required adding [MassStorageDrivers] and [OEMBootFiles] sections to my unattend.txt file and dropping the files in \$OEM$\TEXTMODE and also \$OEM$\$1\PnP\viaraid. Because I consolidated all 5 files into one directory, I did have to make a single modification to the txtsetup.oem file. If someone can detail their exact machine configuration and the methods they've tried (including error messages received) maybe the community can work towards a solution. It just seems to me that while we do have automated methods to make some/all of these source file modifications, it is still a hacky workaround. I don't like modifying files in my \i386 directory ever as 1) it immediately brings you into an unsupported state with Microsoft and 2) you'll have to make those changes to each \i386 directory you'll ever use, including all client and server variations, all integrated service pack points, and any other beta builds you are testing. In addition, separating original Microsoft source files from OEM/corporate customizations puts us in a good position to look forward to Longhorn, which will be using image-based setup only.

This is expected behavior with WinPE deployments. What you should do to eliminate the reboot after running your diskpart script is call winnt32 with the /syspart:C: parameter. This tells Windows setup to make the c: partition the system partition, which will contain ntldr, boot.ini, and ntdetect.com. You can optionally add a /tempdrive:D: parameter to actually install Windows to another partition if you so desire.

The value alluded to above is not related to the extension change warning the original poster referred to. The key HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\SuperHidden corresponds to the checkbox "Hide protected operating system files (Recommended)" on the View tab in the Folder Options dialog. The value "WarningIfNotDefault" refers to the confirmation dialog you get when you uncheck (change from its default value) this box. In this case, the text of the dialog is: The default data of the WarningIfNotDefault value is "@shell32.dll,-28964" (without the quotes). This refers to a resource in shell32.dll. If you have a resource editor, open up shell32.dll, navigate to stringtable resource 1811, and resource 28964 in your language should be the text of the dialog quoted above. To remove this prompt, you should remove or rename the value WarningIfNotDefault. This does not affect the extension change warning.

As far as retail (including Action Pack subscription) and OEM distributions go, Microsoft has a great published way to automate the product key and subsequent activation hassle. The methods below do not apply to volume license or evaluation copies of Windows XP. http://www.microsoft.com/technet/prodtechn...oy/wpadepl.mspx They also provide you with generic product keys you can use on all your CD's without fear of your personal keys getting out in case the CD is misplaced/lost/stolen. The idea is that you use these generic keys in your unattend.txt/winnt.sif file and then use the script within 30 days to update the Windows install with your own real key. For the lazy, the following is the Microsoft published list of product keys you are free to redistribute or use in your unattended CD's. All of these keys are blocked at the activation clearinghouse and are not eligible for activation. Also please remember that the availability of these product keys in no way extends or modifies your license agreement and you still need a legitimate license for all software you use, 30 day grace period notwithstanding. Applicability Product Key Sequence Number Whistler Tech Beta Program (All Platforms) PXRQ3-7VPMV-CQWXR-8Y4KX-RD786 010053298Windows XP Home Edition Full product JKTVX-HCRXC-J2YC9-MX3K4-G9X26 005037750Windows XP Home Edition Upgrade C84VB-JYVFD-P7HF4-6KKRJ-7M6XH 010000182Windows XP Professional Full product DR8GV-C8V6J-BYXHG-7PYJR-DB66Y 005072760Windows XP Professional Upgrade FKTW8-Q7MJ7-JK6GW-9J9RV-HC3C2 010000212Windows XP Home Edition System Builder (Full) KGVXT-F9HVW-XGW9X-QVYVX-HQ9RD 120000613Windows XP Professional System Builder (Full) TTGHK-3RC33-BT9DR-3BVYV-BTQ98 120000607Basically for a home/power/corporate user with more than one Windows XP key and/or computer, use the script at the bottom of the page (WPA_Automation.vbs) to update the product key and activate the machine all in one fell swoop. You'll need to write a function GetProductKey() that will retrieve (your own) appropriate key but the script does the rest of the work.

Might I add: Q833404: Bookshelf Symbol 7 Font Removal Tool Download This utility removes the bssym7.ttf font included in Microsoft Office System 2003, which has been found to contain unacceptable symbols. Unfortunately it's NOT a packaged .msp and can't be slipstreamed into your Office 2003 source. The good news is, Microsoft themselves (are|will be) slipstreaming this update into distribution channels. Depending on when and how you acquired Office you may have this update already, but probably not. May also show up under your Windows Update updates. Q831925: Visio 2003 Update: February 10, 2004 Download Yes, it's only for Visio, and there's only one patch (as opposed to the client/binary and admin/fullfile normal distribution scheme) so you can use this one to slipstream the update or apply it to your client workstations. Visio IS part of Office, even if it doesn't come in any of the suites.

There are a few ways to add the serial number to your Office install. Both methods below work on Office 2000 and above. 1) Add to setup.ini file Locate the setup.ini file in \FILES\SETUP. Make sure the [Options] section is UNcommented (remove any semicolon in front of it if necessary). Add a line in the [Options] section like so: [Options] PIDKEY=XXXXXXXXXXXXXXXXXXXXXXXXXThat should be the word PIDKEY in all caps, an equals sign, and your 25-character product key. Do NOT include the dashes. -OR- 2) Make a shortcut or command script that points to setup.exe and add the command line argument PIDKEY just as above (all 25 chars, no dashes) like so: setup.exe PIDKEY=XXXXXXXXXXXXXXXXXXXXXXXXXBoth ways will prepopulate the cd key field so you can change it before you install but won't need to type it if it's correct. I prefer the first method for "high security" cd's that I know I will not lose track of. The second method I use for network shares or "low security/redistributable" cd's that have a tendency to float away. You can put the shortcut/command script anywhere - it need not be on the CD. Method number 2 will also override any key you've included in your setup.ini file.

This error has to do with your marker files. You'll need at least 3 files in the root of your CD for this error to go away. For Windows XP Pro at the SP1 level, the files are: WIN51 (no extension) WIN51IP (no extension) WIN51IP.SP1 For Home edition, substitute each IP with IC. The file contents aren't important, but the names must be capitalized. Your iso/burning tool may do this automatically.

Here's the registry file I use to set the IE cache to 200 MB. Note that the cache is per-user, so you will need to define the limit in the default user profile before anyone logs on or for each specific user you create. Also, a limit of 2 MB would effectively negate all potential benefit you would derive from the cache. Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Content] "CacheLimit"=dword:00032000 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Cache\Content] "CacheLimit"=dword:00032000You can get the correct value by either setting the cache size to what you want via the user interface and then looking in the registry, or simply use your calculator. In this case 32000 hexadecimal equals 204800 decimal (value in KB) or about 200 MB. Make sure you add both values.

We've covered the component versions that are/will be included in SP2 here. Current plans target May for release.

I felt a little limited by the poll options. I think I got turned on to unattended installs during the Summer of 1998 when I found a little tool on the Windows 98 CD that would allow me to create a batch setup file. I think it appealed to me because I champion using the computer to automate tedious tasks. I always thought the computer should adapt and work for me. Well the antithesis of that is that silly product key requirement during install. I would always end up losing the key or mistyping it or fumbling around for 5 minutes when I knew it should have been installing! When I figured out I could type this once into a text file and never type it again, I was hooked. Later I got into Windows 2000 unattended setups. winnt.sif was a whole new thing for me - it wasn't msbatch.inf and it seemed a lot harder to deal with. I eventually got the hang of it and started exploring more of the customization options. I especially hated the "Documents and Settings" paradigm and wielded the power of the unattended setup to only ever use \Profiles instead. Soon unattended setup became a way to ensure a clean standard setup with minimal work. I didn't get a copy of Windows XP and a good computer to play with until earlier this year, but that was when I really started to spend more time with my unattended setups. I like having a clean install and so I usually format about every 4 to 6 weeks. Wouldn't ever have considered it if I couldn't automate it all. Slipstreaming was a godsend. I don't know how many people ever had to deal with NT4 but it was a joke. While the 9x world was learning to cope with "make a change, reboot the computer" the NT admins were dealing with "make a change, reapply the service pack." The next step was multi-boot CD's. I learned to combine automated and attended installs of Windows on one CD. By the time I landed my current job as a network administrator I could whip up an unattended multi-boot CD in no time. We use ghost + sysprep due to the large number of machines, but I still used an unattended setup because I usually made several revisions of an image before I was satisfied with it, and an unattended setup could be completely documented. As we got new hardware platforms, it also made it a snap to deploy a new image. And here I am now. Home user originally but still make significant use of my unattended CD's at work. Things that I learn in one area usually carry over to the other. It's great for learning new things but sometimes I get mixed up thinking I've already made that change when I really only did it at work. Anyway, that's my story. Home enthusiast, Netadmin to boot. Can I vote for both?

Yeah, the hotfix installation and deployment guide does a wonderful job detailing what to do and Q814847 - well that's one of the reasons I stayed away from hotfix slipstreaming for so long. It's so much hand tweaking, which is of course prone to errors. In an ideal world, hotfixes would be written to support -s just like service packs so we could just slipstream them right in and let Microsoft take care of the hairy stuff. I hear there is something like this in the works for the Longhorn timeframe. Adding, modifying, and replacing components (like WMP/DX/etc) is supposed to be a piece of cake. We'll see I guess. For now, I've slipstreamed RU1 into my XP SP1 CD for work and home using the MSFN guide. As I install XP in so many different situations, however, I've elected for now to keep the other hotfix installations in a separate batch file. I'm not so concerned about having a complete install with one click as I am automating the tedious tasks.

GreenMachine: Fantastic work on that comparison chart! It was really informative as I'm trying to work out what solution I like best. Generally I like to keep as "hands-off" the install source as possible to stay as close to the Microsoft-supported realm as I can. Blaster and Welchia, however have really pushed me into the slipstreamed hotfix world, and it's been a wild ride. Thanks for the info and keep up the good work.

There were really only ever 2 versions of this patch. The original version released 15Oct2003 contains version 5.3.23.4 of update.exe (has problems installing when you don't have the Debug Programs user right) and version 5.1.2600.1301 of msgsvc.dll and wkssvc.dll. This is the version that also does not copy wkssvc.dll to the dllcache. The updated release occurred on 29Oct2003. This one includes version 5.4.1.0 of update.exe and 5.1.2600.1309 of msgsvc.dll and wkssvc.dll. It correctly copies both files to the dllcache on installation. Note that both the 1301 and 1309 versions of msgsvc.dll/wkssvc.dll will protect you against the vulnerability detailed in MS03-043. The only users who will need to redownload are those who obtained the patch before 29 Oct 2003. If you are unsure which version you have, extract the contents and look at some of the version numbers or compare the MD5 sums below. 2e4320d4b52e634c2b3e736728d4b3af *WindowsXP-KB828035-x86-ENU.exe (15Oct2003 release) e9086cefe118e82637996fcebb519e5b *WindowsXP-KB828035-x86-ENU.exe (29Oct2003 release)

The Windows Tour is something I find SO highly annoying I broke down and edited hivesft.inf in my install source. Simply adding this line in the [AddReg] section will turn it off permanently for all users. HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\Applets\Tour","RunCount",0x00010003,0 ;Added 21 May 2003 Generally I will try to keep my changes to more detached methods such as [GuiRunOnce] in unattend.txt and the like (to protect against future service packs) but I wanted to make sure that there would be NO way I would ever see that tour again, no matter what my install method.

For that matter, three patches have been updated. MS03-042 (826232) MS03-043 (828035) MS03-045 (824141) However, this is hardly an issue for anyone to sweat about. For the record, the actual patched files have not changed. (See KB 830846). The only thing changed is the update engine (update.exe), and the issue only affected people who take away the SeDebugPrivilege right from administrators. (If you don't know what that means, don't worry, none of this affects you.) If you've already installed the patch, you're protected and do NOT need to reapply. The end result of using either patch is a fixed system. Carry on!

I guess I was a little unclear. My unattended installation script uses only original binaries from Microsoft. The line ..\Q816093\msjavwu.exe /c:"javatrig.exe /exe_install /l /q" /q:a /r:nrefers to the msjavwu.exe I downloaded from the Windows Update catalog. It's the 3810 "upgrade only" patch. Since I slipstream SP1 (not SP1a), I already have the JVM and hence no need for any funny business. We just patch and move on. (Side note: When SP2 comes out, since I doubt it will have the JVM, I will probably have to resort to installing my Franken-patch on SP2 slipstream installs.) As a completely separate issue, I also did the combined JVM installer thing since I frequently run across users who do not have the current build (or have no JVM) for one reason or another. I wanted to come up with a solution that I could apply to any workstation, regardless of OS or service pack level, or any stupid licensing battles Microsoft and Sun are having this week. Hence the writeup. As far as WinPE installation goes: I am calling winnt32.exe, which (surprisingly!) is the 32-bit version of the Windows setup that you would normally call from within Windows to initiate a new or upgrade install. Dos boot disks can only call winnt.exe, the slow, deprecated, old 16-bit installer. I actually use a "real" version of WinPE 1.2 built from the Windows Server 2003 OPK. Bart's PE Builder, however, is phenomenal, produces basically the same thing and is infinitely extensible. You should have no problem starting setup from a PE Builder WinPE disk. Thanks for the "posted" tip, I'll keep that in mind.

Greenmachine: I include OEM drivers in my several installation scenarios and have never had a problem. This may or may not apply to everybody but as far as I can tell, hotfixes rarely replace driver files so for the most part the "third party driver search" is pretty much useless. I say go for it, but if you start experiencing problems, you'll know the first place you should look. Also, the msjavwu.exe that I use has not been modified. I did have to download it from the Windows Update catalog I believe, but no hex editing - those are all fully supported switches. I didn't do too much for my WinPE installation but I've described what I did in my post in the Win2k/XP install thread in the Windows PE forum (sorry, I couldn't figure out to link to a specific post). Combining the java install into one package was also my doing: see this thread for more details. It's quite simple really. Glad to be a part of these forums, and I'm always looking for more tips. I really do want to hear what you guys think, too. Comments and suggestions welcome.

catpsion: Looks good to me. I usually use -q -o -n -z or -u -o -n -z, depending on whether I want to see what's going on or not. Order of the switches, use of a dash (-) or forward slash (/), and capitalization all have no effect so feel free to keep using what you've got.For what it's worth, here's my current fixwinxp.cmd script I run immediately after a fresh install of Windows XP SP1. Should take care of all critical updates. ..\Q826939\WindowsXP-KB826939-x86-ENU.exe -q -o -n -z ..\Q824105\WindowsXP-KB824105-x86-ENU.exe -q -o -n -z ..\Q828026\WindowsMedia-KB828026-x86-ENU.exe -q -o -n -z ..\Q819696\Q819696_WXP_SP2_x86_ENU.exe -q -o -n -z ..\Q811114\Q811114_WXP_SP2_x86_ENU.exe -q -o -n -z ..\Q816093\msjavwu.exe /c:"javatrig.exe /exe_install /l /q" /q:a /r:n ..\Q823718\Q823718_MDAC_SecurityPatch.exe /q /c:"dahotfix.exe /q /n" ..\Q817787\WindowsMedia8-KB817787-x86-ENU.exe /q:a /r:n ..\Q828750\IE6SP1\q828750.exe /q:a /r:n ..\Q330994\q330994.exe /q:a /r:n ..\Q814078\js56nen.exe /q /r:n ..\Q828035\WindowsXP-KB828035-x86-ENU.exe -q -o -n -z ..\Q825119\WindowsXP-KB825119-x86-ENU.exe -q -o -n -z ..\Q823182\WindowsXP-KB823182-x86-ENU.exe -q -o -n -z ..\Q824141\WindowsXP-KB824141-x86-ENU.exe -q -o -n -z REM shutdown -r -t 0I don't really care for WMP9 or MM2 or any of those other spurious updates so this list will only fix off-the-disc components. Modify as necessary; comments and suggestions welcome.

AaronXP, first of all I want to say you are my hero. I have been working on unattended setups since NT4. The slipstreaming introduced with Windows 2000 I always thought was a good idea but I never messed around very much with slipstreaming hotfixes because it was always so complicated and the frequency of patches emanating from Redmond precluded me from devoting serious effort to each one. My vote is we lobby for hotfixes to support the -s parameter so they can be painlessly slipstreamed to an I386 source just as with the service packs. A few nitpicky things: I noticed you don't include any IIS patches, most notably Q811114. This may or may not be "by design" but I think it's worth pointing out. I use the [Components] section of my unattend.txt to turn on several IIS components during install so I have to make sure that this particular hotfix is applied. The only other case I can see where users would be affected is if they installed IIS components post-setup and then did not use Q811114 to patch, erroneously thinking that their CD had ALL the latest updates. Secondly, you suggest the use of the /Q /U /N /Z parameters for "standard" hotfixes. In this case, the /Q makes the /U redundant. A fairly standard practice for clean installs is /Q /N /Z. If users would like to see what's going on but still have a hands-free install, substituting /U for /Q will do so. At no time should both switches be required. I noticed that before the rollup patch was released my list of patches was 33 lines long. Using WinPE to install my OS took about 15 minutes but applying all those patches took almost as long! When I started experimenting with /U instead of /Q I noticed that for the vast majority of the time spent applying each patch the status text said something like "Creating 3rd-party driver list." After reviewing all of the drivers I was slipstreaming, I decided it was safe to use /O (for overwrite OEM files without prompting). This cut down the deployment time for each patch from as many as 90+ seconds to under 20 seconds in most cases. I do not recommend this for all users, but if you're looking to speed things along, I reduced my patching time from 15 minutes to about 3. I suspect this will significantly reduce that dreaded wait at 13 minutes remaining in a fully patch-slipstreamed install. AaronXP, I just want to say again how much I appreciate your work. I thought I was the only one who ever got into this sorta thing and I can't believe it's taken me this long to find these forums. As always, comments and suggestions welcome.

Lingvo: As I clearly stated in my original post, the ProgramFilesDir and CommonProgramFilesDir entries need to be in the [unattended] section, NOT the [GuiUnattended] section. Please correct your error and let us know how things go for you.

Sorry Carlos I've never had the occasion to do that. Usually I will set aside one partition just for user profiles, and use something like ProfilesDir=E:\. That way all user data is separated from the OS and it's easy for each user to get to his home directory (E:\Bob). Never tried to separate out specific folders like All Users or Application Data, but I suspect you would have a very hard time attempting to do so.