Getting a blue screen everytime I use the DriverPacks with MCE.  Going one by one to determine which one is causing it.  Will update hen I figure it out.  I have a feeling though it is the integrated ATI graphics on the motherboard though...as it seems to be working perfectly fine on other systems.  Doesn't even load up the first graphical stage before it bluescreens...goes straight from the scrolling splash to bsod.  Might be the ATI IGP drivers...

UPDATE:

Graphics A - OK
Graphics B - OK
Graphics C - OK
Chipset      - In progress

BTW...I think one thing that is confusing people is the word image.  It is not an image in the traditional sense or anything...

You have one folder with the windows installation files right from the cd

Another folder with the cfgset for the apps, drivers, oem info etc...

And all WinPE does is "bring it together" on the harddrive...turning your hard drive into the Windows installation disk.

1) Are drivers (and application setups for that matter) included in the image, or are they installed from a share, or are they downloaded from a share by WinPE and then inserted to the installed image?

The application setups are called into play in a completely separate manner.  Using sysprep -factory with a second winbom is how my apps are installed...subsequently on the first complete boot of Windows.   As for the drivers, whatever you are doing works spledidly now...with the exception of MCE.  It used to work for me but now it doesn't...go figure.

2) Can you use WinPE to insert files into the installed image?

WinPE is merely used to partition, format and copy the Windows installation image to the hard drive.  I have never applied the DriverPacks to the WinPE image since the only drivers were need for WinPE are the network and the massstorage...and both are done differently.  Here is what I mean, RIS requires network drivers.  that is it.  But WinPE, when it loads, wants network AND mass storage drivers.  So the .sys and the .inf files get dumped into the RIS \i386 root...while for WinPE the NIC and the Massstorage drivers get dumped into the \i386\inf (.inf files) and the \i386\system32\drivers (.sys files)

3) How and when is the installation of device drivers?

i am using your tools...you tell me wink  I am just implementing them ever slightly differently, but I am not changing any of your work...just moving your files and appended txt.  The DPSFinisher though runs on first boot as the very last thing in my winbom.ini for sysprep -factory (which just so you all know, this winbom.ini file must go into the %systemroot%\sysprep folder that is created when windows is installing.  So that all my programs and everything are local on the installation I put everything in \\opktools\cfgset\*****\$oem$\$1\sysprep folder ...this way the programs all install...and  when you reseal, sysprep deletes the sysprep folder and everything is nice and clean.  Everything with the DriverPacks is the same though.


4) The HAL is automatically set to the correct one?

Of course...because is is an actual fresh windows installation this way.  It is not a RIP prep image or anything.  Just think of it as a "networked installation CD"  I have used this to install on custom machines, Dell, Compaq, EMachines, MDG, Cicero....you name it.  It has been done on P3, P4, AMD, PD, and soon I am gonna try it on a Core Duo 2 wink

and twig...

http://www.microsoft.com/downloads/deta … laylang=en

There is your Microsoft SQL Server 2000 Desktop Engine (MSDE 2000) Release A   wink

oh...and I should mention, WSUS is a bit of a pain in the ass to setup for deployments that might not be staying on that network.  Plus WSUS still makes you reboots and is picky about what is installed in the same pass etc...

That is why I like Autopatcher (plus you can pick and choose your options with autopatcher and then save them and do an unattended "update" with it on Windows first boot.

OK...here is a basic rundown of how I do it...assuming you have RIS installed with the OPK installed on the RIS server (I do it this way for ease of use....plus I like using my RAID5 is what hosts RIS and the OPK since it gives that redundancy against losing all those images...too damn big to back up):

1.  Make a new image on RIS
2.  Make a customized version of WinPE
3.  Add /minint to  the OSLoadOptions in the file:  \RemoteInstall\Setupe\images\****\i386\templates\ristndrd.sif
4.  Copy the i386 folder of your customized WinPE over the i386 folder of the RIS image you created and modified the sif file for.  It will now load WinPE when you run RIS with that image....but it won't go anywhere...yet.
5.  Create your CFGSET that you would normally do with your OPKTOOLS. 
6.  Copy the winbom.ini from the cfgset you created into: \RemoteInstall\Setupe\images\      Now it WILL go somewhere wink 
7.  Apply the DriverPacks to the sku in the OPKTOOLS folder.  typically it will be \\opktools\lang\sku\*****\x86  <--which is where the i386 folder resides.
8.  When that is done, simply move the $oem$ folder from the \\opktools\lang\sku\*****\x86 folder to the \\opktools\cfgsets\**** folder. 
9.  Open the \\opktools\lang\sku\*****\x86\i386\winnt.sif file, copy that information into the \\opktools\cfgset\unattend.txt file (I normally delete the winnt.sif at this point, but it is no necessary).
10.  As far as this goes it is finished...

Run RIS, select your install, PE does its thing and system will reboot and start the normal installation starting in textmode off the hard drive.

as it is right now, I have to do this everytime I create an image...but i like it because:

With any PXE compliant NIC I can load RIS, choose an image, and walk away.  It will partition, format, copy the "windows cd" to the hard drive, reboot, and begin the windows installation from the hard drive...and I do nothing more than login and select.

I have modified my cfgset so that it installs various apps, applies all the updates with AutoPatcher (too many conflicts arise during installation using RyanVM and nLite etc...) and when it is done, it powers off.  I turn it on, it reboots into audit mode.  from there I can verify things work, further perform some updates (make sure the AV is utd etc...) and then reseal.  The end user then has to type in their cdkey, enter in their users etc...just like you would with a brand name computer. 

as for WSUS, I tried it.  I have an SUS server going with all the updates and that, but I like having Autopatcher instead since it will apply all the fixes without rebooting. 


BTW Bashrat, the OPK is available to everyone now!!  All you have to do is sign up at http://oem.microsoft.com and then download it smile  Once you sign up, here is the download page:   http://oem.microsoft.com/script/content … eid=556052    And btw...I am not a big company wink
I for one think if a person has the ability to create a server for this (and it doesn't have to be that grandios)...it is a far superior way of doing it.

as for a tut...I will see if I can find the time to do one.  Between the upcoming wedding, moving, shutting down a business, etc...I have so much on my plate right now...I am surprised I still have a full head of BROWN hair wink

hahaha....I type B T S and it....oh Bâshrat the Sneaky you are sneaky wink   

i was thinking...Wait a tick....I didn't type that! wink

Bâshrat the Sneaky   just had to test this out...

OK, here is how it goes:

I use RIS.  RIS is used to boot a customized WinPE for my network drivers and possibly mass storage drivers.  I implement those 100% on my own manually.  Reason:  WinPE is only being used to prepare the system for Windows installation (partition and format the hard drive and then copy the Windows image to the drive, reboot and boot into the Windows text based installation FROM the HD).

So RIS itself never sees the driver packs.

Let's just COMPLETELY ignore the RIS side of it, for I could care less about RIS since they ar enot used in conjunction with the Packs...and here is why:

1.  PXE loads RIS
2.  RIS loads WinPE
3. WinPE Partitions and formats drive
4. WinPE copies OPK image (this is what you guys would consider your "cd") to hard drive and reboots computer into text mode install right from the hard drive.

The problem is this:

Here is the typical layout of the OPK share...(I will only list the folders I am concerned with):


..\opktools\lang\ENG\sku\*****\x86  <--contains the i386 folder where the DriverPacks are applied and subsequently create the $OEM$ folder...Which I then MOVE to:

..\opktools\cfgsets\*****

And THEN in the ..\opktools\lang\ENG\sku\*****\x86\i386 folder I take the info out of the winnt.sif file, delete it, and paste it into the unattend.txt file in ..\opktools\cfgsets\*****

Follow me?  wink

So you see, I am not using the DriverPacks WITH RIS exactly for my deployments...just using RIS as a platform to access my images.  Works like a damn. And wouldn't have it anyother way.  I use this in conjuction with Autopatcher to automatically apply the updates so I don't have to worry about RyanVM or nLite breaking something...automatically installs OEM software, anti-virus, anti-spyware and last but not least the DPFinisher.  And all I have to do is modify one file and copy the installation files for whatever program to the appropriate folder.  No discs to burn...scratch or lose.  And the only way a person can access them is if they have permission on the domain...and it is faster than cds.  I can install 48 systems in this one room here all at the same time and not have to worry about having enough disks, hardware mismatches or anything.  You just power up, press F12...type a login and a pass...select deployment image press enter twice, walk away and come back in a while and the computer is turned off.  Turn it on and OS is there, drivers are there, applications and all updates are applied and it is ready to have anything else done to it before you reseal it (which then the end user has to type in the product key and activate...unless it is a corporate version of course wink)


I don't know how complex it is to set up the deployment methods, but I am using method 1 for this right now and all Base would have to do is append a different file other than winnt.sif and have $oem$ go to a different location. 

I for one could see this really helping out  system builders out there....h*ll even service people as I have the complete same setup at home for when I have someones computer that wants Windows re-installed.  Allows me to live my life while I make a few extra bucks tongue

If you have any questions about this Bashrat, I would be glad to help.  If you tell me to go fly a kite...well...I can do that too.  wink

don't know which one it is...but with m1 it crashes Base everytime (I am using them all, so whatever one gets called first is causing it to crap out).  As soon as I uncheck 3rd party, works fine.

Hey Bashrat,

I love the packs.  And I am currently using them for use within a non-profit organization which has 100+ computers over mutiple sites (the organization deals with special needs adults and they are getting into youth and children now too...so I frequently do re-installs and can see myself doing way more real soon wink).  What I do though is use RIS and via RIS I load up WinPE and then point  it back to a shared folder also on the RIS server which contain the OPK images (aka cfgsets). 

As it is right now, I apply the packs to the *\x86\ folders that contain the i386es for the corresponding cfgsets.  But then I have to move the $oem$ folders to the cfgset\****\**** folders and then manually edit the unattend.txt files with the driverpaths that were placed in the winnt.sif file. 

Do you think it might be in the cards that one day there will be an option to choose whether the user wants to use a winn.sif or an unattend.txt file that already exists and choose the location of said file...or even better yet, just have an option in the installation platform choices for OPK and then choose your sku and cfgset? 

However, if there is a way someone could point me to a how to so I could implement m2 into a RIS/WinPE/OPK deployment environment that would be great...as I seem to be in the minority for this sort of deployment and m2 doesn't natively work over the network since it expects the packs to be on a cd.

I just like deploying this way because it gives the OOBE (it also make it easier for those not on the domain..ie the "clients" to create users when they get the machine in the group homes), eliminates the need to constantly be creating CDs...as well as it allows me to make sure the corporate keys don't go anywhere by loosing a disc.  I worked for a fortune 500 and within a month of us buying a block, MS blacklisted 'em because one of our unattend discs went AWOL.

Like I said though, it could be handy for those who are in a OEM environment...(which any OEM who does not use the OPK is technically not fulfilling their end of the agreement with MS if they are registered as a system builder).  I had my own business before doing this and that is how I deployed everything so a customer knew they were 100% legit (they typed in their own key) whether it was a new copy of windows or a service re-install.  I never once typed in a customers key.  Nor did I ever use a driver cd (thanks to you Bashrat smile).  This last paragraph was just an enticement to increase the need some might  have for this method, though it is true hehe.

If it is in the works great...if not *sniff*  guess I gotta figure something else out here.

I was previously using Method 1 using RIS to load WinPE and then connect to OPK cfgsets also located on the RIS server.  Everything worked splendidly...until the Driverpaths got too long.

Now I am having difficulties getting Method 2 to work properly...and while I have searched high and low I cannot find anything regarding this.  Has anyone done this successfully?

TIA

JBL