JakeLD wrote:

Tip Of the Day: Use VmWare to make your image and then convert the machine to your favorite image format (ex: Acronis) You can use VMWare Converter. So you don't need to boot in PE emuling an ISO and then take your image and save it to a network share.

Btw, I have been trying to figure out how to do this exactly for a few days now, and I have NO idea how this is even possible considering Converter doesn't support Ghost as an export format.  How do I go about this?

Can I ask why both of these drivers include the DPInst utility in them?  Looks like someone was testing the drivers and forgot to remove it before re-packaging, but wasn't sure.  The utility isn't referenced in the INI file at all for use with the finisher, so thought this might need removed.

Interesting....  Just put the path to the CPU drivers in my DevicePath in the registry, and even had DSPdsblr.exe running during Mini-Setup.  The driver just didn't install at all for me, was using the Microsoft driver from 2004 instead.  Which is ironic because if I have it automatically find the driver after booting up, it sees it and has no signing issues or anything.  I think it's a problem with the driver itself, not with DPInst, or anything else.  Might not be resolvable as a result until AMD puts another version out there.

Well, my results weren't at all what I wanted to see unfortunately, which means OverFlow's theory on the cause isn't right. hmm

If I try to run DPInst with the CPU drivers on the server, and didn't inject the HDC drivers, and removed the so-called "crap-inf" file from the Silicon Image RAID controller folder, I still do get the message about the driver not being available until restarting the machine, which in turn stops the whole process until I click OK.

If I run it on just the local drive, it goes through without error still, but it STILL isn't installing the driver properly.  Here is the DPInst.log file from the process:

INFO:   ****************************************
INFO:   05/13/2008 14:19:33
INFO:   Product Version 2.0.1.0.
INFO:   Version: 5.1.2600 Service Pack 3
INFO:   Platform ID: 2 (NT)
INFO:   Service Pack: 3.0
INFO:   Suite: 0x0100, Product Type: 1
INFO:   Architecture: X86.
INFO:   Interactive Windows Station
INFO:   Command Line: 'DPINST.exe /c /s /sh /sw'
INFO:   ****************************************
INFO:   Option set: dumping log info to console.
INFO:   Current working directory: 'C:\'
INFO:   Running on path 'C:\'
INFO:   DPInst.xml does not list the current UI language.
INFO:   User UI Language is 0x409.
INFO:   Install option set: Suppressing Wizard but no OS popups.
INFO:   Install option set: Running in quiet mode. Suppressing Wizard and OS popups.
INFO:   Install option set: Suppress pre-install of Plug and Play drivers if no matching devices are present.
INFO:   Found driver package: 'C:\D\CPU\AmdAway.inf'.
INFO:   Found driver package: 'C:\D\CPU\amdk8.inf'.
INFO:   Found driver package: 'C:\D\CPU\AmdPPM.inf'.
INFO:   Preinstalling 'c:\d\cpu\amdaway.inf' ...
INFO:   ENTER:  DriverPackagePreinstallW
INFO:   Looking for Model Section [AWAY_MODE]...
INFO:   No matching devices found in INF "c:\d\cpu\amdaway.inf" on the Machine.
INFO:   RETURN: DriverPackagePreinstallW  (0xE000020B)
INFO:   Preinstalling 'c:\d\cpu\amdk8.inf' ...
INFO:   ENTER:  DriverPackagePreinstallW
INFO:   Looking for Model Section [AmdK8.NTX86]...
INFO:   RETURN: DriverPackagePreinstallW  (0x103)
INFO:   Preinstalling 'c:\d\cpu\amdppm.inf' ...
INFO:   ENTER:  DriverPackagePreinstallW
INFO:   Looking for Model Section [AmdPPM.NTx86.5.1]...
INFO:   RETURN: DriverPackagePreinstallW  (0x103)
INFO:   Returning with code 0x0
INFO:   05/13/2008 14:19:34

Now, you'd think that that meant the driver isn't going to work on this machine, but if I install the driver manually through Device Manager, it installs fully and without incident.  I'm going to give this a try with DEVCON I think and see if I can make an exception for this one driver and move on.  Not sure at this point what this all means.

The DPsFnsher or the pre-dating of posts?

http://forum.driverpacks.net/viewtopic.php?id=2700

Trying to get the DriverPacks to work from a network repository for keeping machines up to date with drivers, possibly post deployment, but as I would want to keep those drivers on the server, I want to totally skip deleting them.  Using a read-only share presents an error when trying to delete, though that goes away after a few seconds.

Oh, and please edit this post and pre-date it to 5/13/08 20:22:01 so I look more correct than OverFlow.  Thanks.

*cracks whip*  Go code monkey, go.

Ok, tell ya what... tomorrow I'm going to try the same process with DPInst prior to using the MassStorage DriverPack injected with OSP.  You may be right about this, but I'll be honest, it would definitely surprise me if everything suddenly works afterwards.  The thing about the driver there is that it's not a CPU driver, it's a RAID driver for on an AMD 64-bit system.  It would really be odd if it conflicted with the separate CPU driver wouldn't it?

Thanks for the heads up, I wouldn't have thought of it otherwise.

If this really does work afterwards though, I'm going to remove that INF file and rebuild my BartPE ISO and re-inject drivers again.

Anything else you can think of to try?



Oh, and while I'm here, is there any way to suppress errors from DPsFnsher.exe?  I have the INI set to disable KTD, and of course it's trying to delete the drivers after everything completes (I'm pretty happy now that I made the share read-only!) and it tells me that the INI files on the share cannot be deleted.  The error does go away after some seconds, but just wondering if there was a way to suppress it all.

This doesn't apply to the CPU driver which is the only one I'm working with locally right now.  It just isn't installing the whole driver or something.... the first INF it looks at it finds no corresponding hardware, and the last two it installs fine.  I'll have to get the log when I'm back at work.

Ah, looked at it a little closer and saw that it appears to include a CPU driver there, but I'm not using that at all at that point.  On the hard drive for the local run of DPInst includes only C:\D\CPU, nothing else in C:\D.

Well, it appears that DPInst isn't installing the AMD CPU drivers properly at all.  Not sure the key to it at the moment.  Going to test making an image and pushing it to another computer and see if the other drivers are installing properly or not.  As it is, there's next to nothing to install on the VM.  I'll try this out tomorrow.

NOTE:  The steps listed here can potentially open your server up to unwanted access from anonymous users.  Please, please read the documentation from Microsoft about Null Session Shares, Anonymous Access, NTFS Permissions, and Sharing Permissions and understand what it means to allow them prior to using these steps.  These steps are meant to be a simple set of steps to make sure you can get everything up and running with minimal effort, and does not take into account the myriad threats that may exist within your environment.  I cannot be held responsible for any security attacks that result from using these steps.  Keep in mind, this is not the ONLY way of accessing drivers across the network, but it does make it the most seamless as I can imagine doing it.

Here are the steps to make a share on a Windows server so there is no authentication needed and no complex scripts are required either (don't worry, I'm pre-med... or was that pre-law?):

1.  Go into Computer Management (either right click My Computer and use Manage or Start > Run > compmgmt.msc).  Navigate to Computer Management (Local) > System Tools > Local Users and Group > Users, and then enable the Guest account.  If this server is a domain controller, you'd have to do this in Active Directory Users and Computers instead, but I'd highly recommend against doing this.  Instead, use a member server or you may have unwanted access to computers via the Guest account elsewhere.

2.  Extract the DriverPacks to a folder on your server.   Keep the INI files and make sure to keep the D folder as part of the folder structure.  E.g. On the server I used, I made a folder at D:\Drivers.  Inside of that are all the INI files and the D folder which contains the C, CPU, etc folders.

3.  Go to the properties of your Drivers folder, go to the Sharing tab, and enable Sharing.  Use whatever you'd like for your share name (I just use Drivers).  Whatever you use here, remember for later on in Step 6.

4.  Click Permissions.  Here, you'll want to explicitly add Guest with Read permissions to the share.  Make sure you are adding the local computer's Guest account, and not the domain Guest account.  I also remove Everyone from the list.  The only time this share will ever be used by me is when I'm imaging and read-only access is all I will ever need.  Click OK after you have added Guest and given it proper permissions.

5.  Click the Security tab.  Here we'll want to add the Guest account and give it Read & Execute permissions.  Note that this is different than Sharing permissions, and if you don't understand the difference, you'll want to do some reading on what the differences are.  I tend to explicitly state what a user can do in both Sharing and NTFS file permissions.  Again, make sure you are using the local Guest account, and not the domain Guest account.  Click OK to accept changes and close the properties window for your shared folder.

6.  Now for adding this share as a "Null Session Share".  Open REGEDT32.exe and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters.  Open the value NullSessionShares and add a new line at the end with your exact share name used in Step 3, including the trailing "$" if you were making a hidden share.  Make sure you don't remove current data in the value (should already have "COMCFG" and "DFS$" and possibly more depending on your config).

7.  Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.  Create a new DWORD named restrictanonymous if one does not already exist and give it the value of 0.

8.  (XP/2003) There is also a DWORD setting at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa for EveryoneIncludesAnonymous.  The default of 0 is used to differentiate between authenticated and anonymous users.  If you leave this at the default of 0, you MUST explicitly give the Guest account access to each individual resource, including file permissions and share permissions (as I stated that I use above).  If set to 1, this is optional and you may use the Everyone account, but I would suggest you allow for the XP and 2003 security mechanism to function as intended.

9.  Reboot your computer/server and you should be able to test your share by using this command:  NET USE \\<servername>\Drivers /user:""

Just thought I'd start a post about this since I've been working on this for a little while, with limited success.  Thus far, I've tried running DPInst from C:\ and I've also tried putting DPInst on the share and running that directly.  Access to the share out of the equation (read-only access is set up, and appears to be working fully as intended), I'm having a problem with the AMD CPU drivers, and (though unconfirmed) nothing else.

As it is, I get a prompt from the Hardware Installation Wizard that there was a problem installing this driver and it won't be available until after the next restart.  I have tried "/c /s" as the parameters and used the DPinst.xml file included, and have ALSO tried changing to using the parameters "/c /s /sh /sw /path \\<network server>\Drivers".

I have changed the DPInst.xml file to only have the <search> and <subdirectory> parameters, using "*" as the directory as per the DPInst information on Microsoft's site.  That doesn't really seem to make any difference to the CPU driver though, just things I've tried.

So far, I am of the thought that if I remove the CPU drivers from network, things should work just fine.... but I didn't have one oddity in my testing that makes me question just how well all of this is working.

I tried to leave the CPU drivers on the local computer, and run DPInst (also locally) on the local path (C:\D\CPU).  It had worked before in testing using all DriverPacks together, so I thought this would be a non-issue...  then I got the same error message.  I actually had set up two completely separate entries in ROE for DPInst, one that used a copy of DPInst.exe and DPInst.xml on C:\ and pathing to C:\D\CPU.  I hadn't even gotten to the second run of DPInst (which was completely contained on the network server) when I again got the same error.  It most likely was something I did that is the problem here.


Now that I'm thinking about it, I might not have tried with the XML file supplied with DPs_Base for the CPU-only set of drivers on the local machine.  This I cannot say for certain, but I do think it would be a good idea for me to try that again tomorrow when I get a chance.

I'll try to keep you all up-to-date on my status on this implementation and any idiosyncrasies I run into.

Galapo wrote:

Of course! Version 2 is going to offer this as an option. From memory, I think the coding for this has been done. But note: driver injection into a RUNNING system is not as neat as for an offline one. So to inject drivers into a running system, the conventional way of using sysprep.inf must be used.

Regards,
Galapo.

Hmm, ok.  I'll probably just use the conventional way if possible then.  I do like the idea you and others came up with to inject drivers without installing services, so yeah, it's not as neat using the SysprepMassStorage way of doing things.  And I did manage to get Windows Server 2003 SP2 x64 and got the NTLDR.  All appeared to work just fine as others mentioned, I didn't not get the error (FASTFAT.SYS in my case, not NTFS.SYS since I do the conversion to NTFS later).

Thanks OverFlow ... I did have to make one ammend to my post though.  Realized I had mentioned making a 2000 image, and had also mentioned using Dial-a-fix as part of my imaging routines, but those together can cause some major problems and break service dependencies.

Edit:  Galapo, another thought since you're on the subject of revisions to OSP - any chance you could make it so that some features will still work on a running install?  I'm sure some functions shouldn't be ran on a running partition, but things like injecting the drivers would be nice to not have to boot into a BartPE ISO (Yes, I'm being lazy here, just humor me and say THAT'S UNPOSSIBLE, thanks smile)

Sorry, that was a typo, I meant SP2.  Was thinking XP 64-bit and 2003 altogether.  Will edit that post right away.  And I always do a full PNP, I don't care about the time required - I'll just go on to doing other things while I wait on it.  Just set VMWare to idle priority and it doesn't normally interfere with work. smile

Galapo, wow....  that's a great idea.  I would so love to use that as the method for changing HALs.  I'm all for that. smile

Well, it isn't a choice between using Ghost or Sysprep if that's what you were thinking.  I use both, they are part of the same purpose of getting the image to the computer.  I don't use Norton Ghost though, I use Symantec Ghost which means every machine also has the client software to take commands.  This includes being able to tell the client I want to pull and image from it, or telling it I want to push an image to it.  Or even push out pre-packaged software, such as Microsoft Office (I use both XP and 2007 packages for different reasons), OpenOffice, and other tools as well.  Things that don't have to ever be part of the main image, things that might change from laptop to desktop, from administrative use, to lab use.

My imaging process is fairly streamlined, and I can make a brand new image from install to image creation in about 3 hours.  I have a checklist, but it's more of a guideline for me, I have most of it all memorized and I'm fairly structured in how I go about it to give myself reminders (like going through the Control Panel from beginning to end, no stopping to go do other random tasks).  Also if I run into an issue, depending on how severe, I may start over, but that very rarely happens.

My steps, to keep general is like this:
I install Windows to a VM (I use VMWare Workstation for the more robust snapshotting abilities) after having prepared a copy with HFSlip, then using nLite to create the Unattended settings (I do NOT remove components, that has always ended up with trouble for me in Sysprepping and other unforeseeable circumstances) and make sure to force the standard PIC ACPI HAL (though not the "Standard PC" HAL of course). I do use the tweaks section though, and I do disable SFC (I'm making an image, why would I use System Restore to fix a computer?)

I have an "Installs" folder on my host computer that I copy over to my VM.  It includes .Net 1.1 through 3.5, Adobe Reader, QuickTime, IrfanView, Java, Shockwave Player, Sysprep, and a few other things.  Several of these things are automated installs, some aren't, but all of them are very basic.  No productivity software at all, no content creation, just codecs, frameworks, viewers - that kind of thing.

I set up the local Group Policy on the machine (I also have a domain policy, but I use just basic settings that I want on every machine, even those that aren't added to the domain, such as my WSUS server settings).

I use CCleaner to clean up all my settings and temp data (also on the Installs folder, not installed on the VM) and then after that making the user my Default User template.

I change my HDC to the standard IDE controller.  Before using Sysprep, I use Dial-a-fix (if you use 2000, read the note at the end of this post) to clean up all the system temp stuff, clearing out the CatRoot2, and cleaning up all the Windows Update caching.  Just prior to running Sysprep I make a Pre-Sysprep snapshot in VMWare.  Also I run CONVERT.EXE to say on the next bootup to convert to NTFS (I install to FAT32 to make sure I can edit the image if I forgot anything or whatever maintenance I need to do - I'd suggest EVERYONE do this as NTFS, even in Ghost 11 is not reliable).  I use MySysprep to allow for detection of the HAL during Mini-Setup which then will modify my sysprep.inf for me only if needing the MP APIC HAL.  I also have my DriverPacks on the image, uncompressed (I would rather Ghost do the decompression once than making me wait for un7zip to finish ... caused me problems on 2000 before).

After Sysprep finishes and shuts the computer off, I then boot from an AMD PCNET ISO for Ghost I made, and send the image to the server.  Then delete my admin profile (I leave no profiles, just the default user).


Basically, what happens when I image a computer is this:
I either boot from a DOS CD for Ghost that I made for all the different NICs I have, or send a task to a client machine to receive my Ghost image.  So I typically have 2 to 20 machines all imaging at once.

When they finish that, they boot up, detect that they are on FAT32, run a CHKDSK, convert to NTFS, reboot automatically into Mini-Setup.  MySysprep detects the HAL needed, sets it to MP APIC if needed, proceeds through.  The computer will then reboot, auto-login to my admin account (which has no password initially since Sysprep SUCKS at setting the password, e.g. it can't reliably) and then through ROE mechanism running DPInst and the DriverPacks Finisher.

When I see they are all at the desktop and ready to go, I send a task to send whatever packaged programs I want (Office, etc) and also set the password to the admin account through the NET USER command.

After that, I have Ghost add it to the domain using my config template I have set up for my AD domain.

To put it simple, I don't use Sysprep as a means to create an image file (it doesn't do that anyhow), I use it as a tool before making the image file.

God I hope this doesn't double post... lol


* About Dial-a-fix on Windows 2000 - make SURE if you are using Dial-a-fix on a 2000 machine, you understand what the "BITS Superfail" is all about.  Look it up on DJLizard.net and make sure you follow the revised steps that he and I talked about to make sure you don't break Automatic Updates and the Windows Update site entirely.  If you don't read up on this, I absolutely guarantee you will break your 2000 install because of some bug in Microsoft's API for registering the Automatic Updates DLL files.

I've never used VMWare Converter, but downloading the Starter Edition right now to give it a try.  Yeah, I use VMWare Workstation for everything when creating images... Used to do it on actual machines, and then made a pre-Sysprep and post-Sysprep image.  Now I just make a pre-Sysprep snapshot and make one image.


Hmm... downloaded it, but don't see an option to convert TO a Ghost image.  I know I can convert from one, but not seeing the option I need for making the Ghost image.

If I were playing WoW I'd blame the hunter, even if there wasn't one. smile


Anyhow, on topic, I'm going to try something with my Sysprep-ed image.  I'm going to set up as I normally would, but going to use OfflineSysprep for injecting drivers ONLY.  I know this isn't the intended function of OfflineSysprep but I see no other easy way of injecting the drivers the way OfflineSysprep does, and I still am going to use MySysprep for it's HAL detection mechanisms (it really does do a good job and allows for a lot of customization on how it is detected).  Anyone have any advice on whether this is a good idea or not?

Edit:  Blah, downloading Server 2003 SP2 64-bit right now to get the NTLDR file for use with it.  Hopefully that will fix my memory problems as some others have mentioned.  (Well they said XP, but it's really the same thing on the 64-bit side.)

Hehe, ok with OverFlow's mention of not liking Sysprep, I guess it would be appropriate for me to say why I use Sysprep.  Maybe this is precisely why you do as well.  Unattended installs of Windows is great and all, and for many people, OverFlow included, it suits their needs of getting a Windows install prepared for a new computer.  But here's where you have the problem - if this computer is assumed to be ready to go, with ALL settings already prepared, including removing certain shortcuts, setting up specific permissions, making sure to disable all the different automatic updates for some programs (I don't really want people to worry about Java or Flash needing updates), etc, then running Sysprep is the more suitable way of deploying.  I do go through all the trouble of setting up the Default User account, and the end-user's experience should be identical on every machine.  I have a large number of domain users, and they should feel free to go to many different computers and expect to not have the same welcome screens for every program they use the first time they ever use the computer.

Here are some of the (dis)/advantages to Sysprep:
ADV - The computer can be ready to go from the time the user signs for the very first time.
ADV - Less time instructing users how to get started on a piece of software you include into your image as you should have taken care of all the software defaults before they ever sit down.
ADV - If there are any changes that need to be done to your image, you can do it from the comfort of working with Windows, not from looking at an AutoIT script or however you prefer to automate an install.  You'll know it works (with the obvious exception that some software has their own bugs) when it's deployed and don't have to test a full install for a single setting change.
ADV - Less time is needed to learn how a particular installer works.  Normally when you find a program you need to install for an automated installation, you have to learn how to work with the silent install options, finding out how to remove components you don't want or changing the at-install settings with AutoIT.  You can just do it yourself as you would with any other software install.
DIS - Probably the biggest disadvantage - the chance of security-related problems such as leaving credentials on the computer for logging into remote servers, saving passwords to sites, etc while you are preparing the Default User profile is always a threat.  Make sure you clean up your tracks very well before making a Default User profile.  I prefer to do everything from a command prompt (including connecting to network shares and opening up programs) and running CCleaner on the profile prior to making the copy to Default User.
DIS - Requires a lot of thought on how the user experience should be.  You have to take into account everything, and figuring out the "best" settings for every individual application is time consuming and requires a checklist to be made so that you remember to use those same settings everytime you "rebuild" your so-called perfect image.
DIS - Drivers have already been loaded for the machine the image was created on and you have to go through several steps to make sure those drivers are available on first-boot as well as for Mini-Setup.  Expect to run into many many many BSODs as you learn the tricks of using Sysprep (did I mention MANY?).
DIS - How you handle working with HALs can seriously affect how you deploy your images.  There are a few different things you can do, including making multiple images, one for the standard PIC ACPI machine and one for APIC Multi-CPU (and possibly one for APIC Uni-CPU if you really feel it's necessary).  Personally, I've been using MySysprep - looks ugly during Mini-Setup but gets the job done.

There's a lot of other things too that I'm not thinking of at this point, but that's just to get you started on why you should or shouldn't use Sysprep.

*clicks Submit and winces at the chance I will double, triple, or quadruple post again*

Ok, seriously now... I do have my coffee in the morning, but I know how to single-click the Submit button.  lol am I the only one having problems with double posting?

Damn, server kicked my post out with a "Server Too Busy" message...  anyhow, to put it short, thanks Jaak for the scripts.  Used it for HDC drivers and made 2 lists (2000 and XP), removed all duplicates and 2003 references, and came up with two 94KB lists.  Going to try them out here in a bit, and see how incredibly long it takes Sysprep to run.  Going to also add into it the lines from 2000 Sysprep sample docs to have all the built-in drivers working too.

I think I love you.

If it's still available, I'd be very surprised... I've been looking for it for like 8 months now without success.  hmm  If you DO find it, please, send me a link to where I can find it.  Been wanting to add that to my UBCD4Win disc for a long time, but have been settling for using other tools.

What I really wish I had was a copy of Longhorn build 4051 for the NTLDR from that.... god, having something that has a built-in HAL detection would be so much more convenient.  Yeah I know, legal issues there too unfortunately, but I'd still like to try it regardless, at least to test things out.  Oh well, I might be out of luck.