sintaxasn

I did something similar to this a while ago: http://www.msfn.org/board/index.php?showtopic=43483&hl= and I think someone else also did a batch file version.

Well, now it exists in VBS too

Hey there, If you're like me and you have an automated build solution that creates an image, you probably use Sysprep at the end to seal your machine. Adding new hardware support means putting all the drivers into a folder thats copied down as part of your build, and manually adding the folders to C:\Sysprep\Sysprep.INF in OemPnPDriversPath. This was bothering me, because I had a line that was about 2000 characters long and prone to typos, meaning your driver never got installed - plus you had to manually edit your Sysprep.INF. So I spent a bit of time writing this VBS file which will scan C:\BIN (or C:\Drivers, or whatever you want) for INF files - when it discovers one, it'll add it to your OemPnPDriversPath line. It's smart enough not to add duplicates, sorts alphabetically (so 00_Chipset will always be the first item), and lets you know if you exceed the 4096 character limit. Just download and rename to .VBS, add somewhere so that it runs prior to Sysprep starting and that's it. In future, all you have to do is pop your drivers into the folder somewhere at it will automatically pick them up and put them into Sysprep! Almost forgot - it needs AutoItX - it could be done without it but I got lazy. Just get it at www.autoitscript.com Hope this is helpful to someone... Dan BinScan.txt

Ok, I got rid of my SVCPack.INF and SVCPack folder and rebuilt it with all patches. Same problem at the 885250 patch. Soooo... I have a fully up to date SVCPack.INF and SVCPack without the 885250 patch. I renamed both of these and ran the 885250 patch with /Integrate:xxxxx. So now I've got a new SVCPack and SVCPack.INF with just the files I need. I take the .CAT and .EXE files from SVCPack and put them into my old SVCPack folder. Then I edit my old SVCPack\HFINT.DAT file and add the following under the relevant headings: [FixesInstalled] KB885250 [branches] KB885250=SP2GDR and add this section at the end [KB885250] mrxsmb.sys I dont know will this cause problems with the [KB885835] section, as it also has the same file, but I'm rebuilding now and dont seem to have any problems. Then I edit my old SVCPack.INF and add the following under the relevant headings: [setupHotfixesToRun] KB885250.exe /q /n /z [ProductCatalogsToInstall] KB885250.cat And then obviously move the stuff back to the right locations and that solves my problem!

hey guys, i'm also seeing a problem integrating this patch. All other patches have integrated fine, but this seems to be caught in a loop during the update process. It keeps activating and deactivating the active window (if that makes sense). Looking in task manager shows three processes relating to it: WindowsXP-KB885250-x86-ENU.exe Update.Exe KB885835.Exe KB885835 keeps disappearing and reappearing, which would explain the window jumping stuff. It's like Update.Exe is getting a bad errorcode from 885835 and rerunning it each time. Both 885250 and 885835 seem to contain updates to the file mrxsmb.sys, so i think there's some sort of conflict there. Any ideas? Cheers, Dan.

Thanks for that. Found this - http://www.jnux.net/community/hal/ ok - so it seems pretty possible. Now, it's possible to pull hardware information from WMI and match, say a PC model number with the correct HAL info. but, this means maintenance of an INI file with HW models. It'd be nicer to not have to do this. Since Windows seems to be able to identify the HAL type itself during a full Windows install, my question is, how? Is the same info available through WMI or using a util to read BIOS info? Any help would be appreciated. Cheers, Dan.

Hmmm.... My HAL contains Generic entries, and one Compaq entry. In total, around 6 different possibilities. Off checking around in WMI to see if I can find anything to do with HAL....

Hey Risla, I actually use Ghost and standalone DVDs to create my image(s), but yes, same idea. If you look at C:\Windows\Inf\HAL.INF, you'll see what I mean about the HAL copy. I've read somewhere (possibly JSI Inc?) that there IS a common HAL for all machines which are post 1999 (all ACPI compliant I think), but it's not optimum, as it doesnt account for Uni/Multi processor etc. Is it just me, or does anyone wonder *WHY* XP wont replace the HAL itself? It this theory works, then there's absolutely no reason why it cant be done as part of Sysprep, a la Mass Storage. If anyone has some decent info on the HAL, please let me know. All the info I've seen so far is vague at best. Also, have looked at that Universal Imaging Utility, but I'm loathe to add another 250MB onto my build (which is already 5 GB), and fork out 10 - 20 $ per seat. Cheers, Dan

Hey guys, I know a few people here are probably in the same situation as I am - you want 1 universal image for all hardware types. Right now, I use an unattended XP install to build my image. I dont have any driver paths set in WINNT.SIF. Instead, when my image is finished being built, I run sysprep. my sysprep.inf has all the driver paths. This way, when I load the image on, say an IBM T40, T41, X31, X40 etc. It loads all the correct drivers, with no residue of the others. Good right? However, HAL is still my major problem. Right now I have to have two images - one for laptops, one for deskstops. All my desktops have Hyperthreading disabled - which means they're uniprocessor essentially. I want to re-enable HT, which changes the HAL type - whichmeans a third image! From what I can establish, you *CAN* reset the HAL prior to taking your sysprep image - to a common HAL that won't bluescreen every machine. However it's not the optimum HAL and you shouldn't really do it. I'm wondering if anyone is interested in working on this issue with me. Essentially I need to get as much info on the how's and why's of this HAL problem as possible. My idea is: Prior to sysprep, automatically reset to a standard HAL. Take your image Load the image on a machine. During RunOnceEx, use WMI to determine the machine type, reference an INI file with the details of HAL types for different machine models, and swap back to the optimum HAL (would use CMDLINES stage but WMI isnt available then). From what I understand, the HAL is 1 DLL file and it's always HAL.DLL. So an ACPI uniprocessor system copies HALACPI.DL_ to HAL.DLL, an ACPI multiprocessor system copies HALMACPI.DL_ to HAL.DLL. Am I totally wrong, or should this be fairly easy to do? Thoughts/comments etc. Thanks, Dan.

Prathapml - unfortunately if the password is randomised during the CMDLines.TXT phase, then the autologon wont work. If anyone's interested, I've written a small exe (xAuto.Exe) which will give an additional autologon each time it's run, in a random password environment - provided that the random password is also passed to the exe at the same time that it's changed. It also works in Novell environments (using Novell Client), and if a machine name is being changed during the same reboot. Usage would be as follows: Set Password=%RANDOM% Net User Administrator %PASSWORD% xAuto %PASSWORD% if you've just changed the machine name (will will become active during the next reboot) you use xAuto %PASSWORD% /Asset:%NEWNAME% When you're finished autologging on as many times as you want, you just run xAuto /DEL to clear up some Novell keys (specifically autoticking Workstation Only logon) Hope someone can find some use for it. Dan

Further to this, you could hide the Multiplication value somewhere in the registry. and before you reboot, or sysprep (or whatever), use another vbscript to read the multiplication value, plus the additional bits of info you've set in the registry - decrypt the password, and set the autologon information. Again, this will only work once (that's assuming that you run the vbscript to randomise the password on EVERY boot as I do). Hope this helps! Dan

Hey there - not sure if this is helpful, but what I've done is use a vbscript to do the following: Set a static multiplication factor Get the current time Add the hours, minutes, day month year etc. whatever you want Generate a random number Multiply the factor by the total time value and add to the end of the random number Set the password to this value Then on the CTRL-ALT-DEL page, I change the heading using this key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\LogonPrompt to various bits of information, including the time and random number disguised. Further to this, I've created a tool that our helpdesk can use to supply a "one-time" admin password by asking the end user for the info on the C-A-D screen. I've already hardcoded the multiplication factor into the tool, and it basically decrypts these values and provides a usable one time password. This way, no-one knows what the passwords are at any given time without this utility. It's kindof a basic Challenge/Response system, but the ideas behind it might be what your looking for. Cheers, Dan

Nobody ?

Hi guys, I'm working on a flexible build process that goes as follows: Standard WINNT.SIF used to build initial install T-13 build type selection utility install custom apps Sysprep At that point i'll be taking an image to load on various machines. My problem however, is I want to be able to use my built type selection tool to set the default theme for all users. I know you can do this at the WINNT.SIF stage, but that doesn't help, as I need to be able to do this at T-13. Is there regkeys I can set for HKEY_USERS\.DEFAULT (for pre-logon) and HKEY_CURRENT USER (default user profile) to use a specific theme? I haven't quite been able to figure these out. Additionally, is it possible to specify a theme colour at the same time? Thanks, Dan.

Hi Guys, I was wondering if anyone had any information regarding the legal use of the Energy Blue theme. I'm working on a company wide XP deployment and a lot of people have seen Energy Blue and expressed an interest in having it the default theme. It's cleaner looking than Luna. However, as it was intended for use on Tablet PC, and you need to bypass the original Microsoft Exe to get it working under XP, I'm not sure if we're "allowed" to use it, even though it's digitally signed by MS. Anyone have any info or thoughts on this? An official stance would be great but probably difficult to get Thanks, Dan.

Anyone?

Hi there, I'm looking for a way (regtweak if possibly) to set the initial size of the QuickLaunch toolbar. I add about 8 icons to the toolbar, but when you log in as a user, only the first three are shown, untiil you manually resize it. I've tried doing SetupCaptures in Wise Package Studio, and thought I had it narrowed down to the correct key, but if I apply the key, even with Explorer.Exe not yet started, it doesn't size the toolbar to the correct size. Is there any way of setting this to automatically resize to the proper size, or manually set this for all users on the machine (possibly something added to the Default User Profile?) Additionally, does anyone know what regkey I change to have the taskbar set to unlocked? Thanks, Dan.

hey, In our environment, we have a Volume License edition of XP which has the same key for all workstations. There's no problems with Windows Update then. There's definately utilities out there that will change the CD after install. Do a search on google. If you're using a ghost image and don't need to do this through an unattended install, the easiest way is probably changing the group policy settings. Start > Run > GPEdit.MSC. It'll be in here under administrative templates somewhere. To change the OEM logo, put a small bitmap into C:\Windows\System32 and call it OEMLOGO.BMP And sorry I can't help on the printers question! Dan

So I think I've figured this out and I'm sure I'm not the only one that's run into this problem so I figured I'd post my method. I'm not a complete genius with MSI technology - I wasn't paying much attention in the course I went on , so if this is wrong, someone correct me. There's two ways : Firstly, the straightforward method - that's to add to the SOURCELIST property. Windows Installer maintains a list of source paths for each install. When you install an MSI, the location your installing from becomes the first location on the list. By using the SOURCELIST property, you can add up to 26 sources, comma-delimited. ie. D:\Install\Acrobat\Acrobat6.MSI /QN TRANSFORMS="D:\Install\Acrobat\Custom.MST" SOURCELIST="\\CORPSERVER\Install\Acrobat,K:\Install\Acrobat" This would install Acrobat silently, with my transform. Additionally, if Acrobat ever needs to be repaired or patched, It will look for the source files on your D:\Install\Acrobat folder first, then the UNC patch \\CORPSERVER, and finally on the K: drive. When it finds one that exists and matches the GID of the current MSI, it'll pull it's info from there. If it doesn't find a match, it'll prompt for an install location This is incredibly useful in corporate environments as you can place all your MSIs in more than one location, providing redundancy should a server go down. The second method is the one I opted for, and that's to modify the original MSI with a VBS file I found on DesktopEngineer.Com, called CA Reset Sources. From what I understand, it adds a custom action to the MSI which says that if the RESETSOURCES property exists, to use that as the first source location. This is great for me as I know users won't be installing from a DVD again, and so it avoids the delay in searching the DVD drive for the required files, speeding up the process. To use it, you just run the VBS file with Package="yourmsi.MSI". Then just use the RESETSOURCES property on the commandline to specifiy the new source location. There's also a util with the VBS file to change MSI source locations after an MSI is installed, which would be very handy if say, your main deployment server is being renamed or something. Hope this helps someone! Dan

Unfortunately not. This only modifies the Locally Cached Source, which is a feature of Office 2003 and no other MSI files. One example is during an unattended install, if I auto install Acrobat 6.01, followed by 6.02 update, when I first go to use Acrobat, it runs Windows Installer to do some additional steps, and looks for the source files. Firstly, I don't know why this is happening - as far as I'm concerned, once you install an MSI, it should need the original incase there's a problem. Secondly, in a case where there IS a problem (corrupt or missing files, or a repair is run on an app), I want to have a central location on a server where users can still access all the files, without having to pop back in a DVD. Any ideas anyone? Thanks, Dan.

Hi All, I'm trying to build a corporate standalone DVD for users to install XP with all the required software. Once the install is complete, I want to repoint all the MSI's from using the DVD as a source location, to a network location. ie. MS Office 2003 installed from DVD User adds new feature Windows Installer prompts to insert the DVD. I want to change this so that it will look to a mapped drive or a UNC path instead of the DVD drive. Does anyone know of any utilities that can be used to do this, or is it somewhere in the registry that I can change? Thanks, Dan.