dim

I am just curious if someone can help me confirm my thoughts. We have ESX 3.5 environment and we are working on our automated solutions for Windows 2008. In the initial WinPE pass we format Drive C and Drive D and Drive E per say. Drive D is our pagefile and Drive D is apps and we format that NTFS and change the cdrom driver letter and all the disks show online and everything looks great. After Windows installs and reboots to start the finishing installation process all the remaining disks other than boot disk appear offline in diskpart. We are only seeing this on Windows 2008 x86. Windows 2008 x64 works fine. Can someone please confirm they are seeing this if they have a similiar environment to test with or provide insight. thanks dim

I am not sure what the issue is. This should be pretty straightforward. Are you using Windows System image manager? Add the Foundation Pack to your XML file and chose your roles and options

We have moved on With DataImages as Microsoft suggested and it works awesome.. better than $oem$ ever did...

Look at NetSH command. You will be able to get everything you need through that command

After the unattended installation the files get copied to C:\Windows\Panther All files need to be removed when you are done.

But.. On another note, I do have some more questions regarding dataimage... I will have to do some research.. What about the $$ structure .. Does all that go away?

CCGuy Exactly... Maybe my terminology is off, but that is exactly what I was stating before. I am moving towards DataImages. From what i read from your post, it sounds like you are taking the install.wim file and injecting stuff into them. That is not my understanding of DataImage. My understanding of Dataimage is you create a custom WIM file and associate it in your unattend.xml file. Once the system comes up, the files get extracted to the root of the systemdrive. In my opinion, it doesn't touch the actual source, install.wim. Now the tricky part is how to dynamically create a dataimage and then associate it in your unattend.xml file. How does that sound?

CoolComputerGuy I haven't seen that documentation, but i personally am not a fan of injecting into the install.wim file. To me that doesn't allow the flexibility of a true scripted installation... I am toying with the idea of using imagex and capture the associated drivers per hardware platform in WinPE and haveing a generic driver folder in the audit pass for PNP drivers.

Max- I appreciate your advice. I am a believer of leaving the base WIM intact b/c by creating a process that injects drivers into the WIM file doesn't quite allow for the flexibility.

We are not image based.. We are scripted install. We must use setup.exe /unattend:unattend.xml.

Thanks for replying to me... Now can you help me understand if I am using let's say Altiris to deploy images via scripted installation and not image based. So I am lauching setup.exe /unattend:unattend.xml what should I be looking at most to allow for the most flexibility of adding new hardware. I want to try not to update the install.wim file itself, but be able to add flexibility. For example, with our old windows 2003 builds we dynamically find out our mass storage drivers based on hardware and then dynamically write the unattend.txt file on the fly and launch the installation. I don't see this as a viable solution for w2k8. All your help is much appreciated.

As I posted previously, I come from the school of W2k3 scripted unattended installations. We like the flexibility of changing on the fly. Now, What should I be focusing on with Either Vista or Server 2008 for scripted unattended installations via a network share. In the past I created the $oem$ and $$ and $1 directories and put all the information in there. I have been reading about configuration sets, but I am not quite sure I 100% understand this. I basically have network shares that usually store our source files globally, so how can I do this with Windows 2008?

Hey All - I am working on getting Windows 2008 Automated so I am getting familiar the night and day differences in Unattend.txt and unattend.xml using WSIM. My question is, we use Altiris Deployment Solution with Altiris Notification Server configured with regionalized Package Servers to distribute software based on AD Sites and Subnets. So, in the past we determine the local package server and then pull the installation files from the local repository. With the old Windows unattended installation it didn't care where the install was from. But with the new unattend.xml, I am not 100% how that works. I see traces of the Install.wim file location. If that is the case I need to dynamically update this file. Any help on where I can locate the source files and update the xml file would be greatly appreciated. Thanks

I don't see an issue with it. I am not quite sure why you are using the id=byte/guid. Please explain. I assume you are doing desktops so you don't know need dynamically find the primary disk ID.

Jaz - I am going to reconfirm, but I think I added all those drivers...

Jaz - Bad news.. That enty is already in the VMX file. Any other thoughts.. Man, I wish I can show you how slow the file copies are.. It's like watching paint dry.. The Networking says 1GB on the vm, but its totally lying..

Jaz - I will give that a shot.. Also, know that once Vmware tools gets installed on the OS, it works like a charm.. Super fast...

Jaz - Ok, I went back and doublechecked my work.. I don't get it.. I have imported all the drivers in the proper fashion, but the **** winPE x64 on vmware is still really slow... For example, I have a script that runs for automated builds and it does lots of file copies. You can actually see the script working through line by line and copying the files line by line.. So Slow.. The same script on x86 WinPE flies by, and in a blink of an eye, the script is complete. Can you load up your Vmware x64 winPE and see if you file copies are extremely slow as well? Thanks Josh

Jaz - Ok, that is exactly what i did as well. I read the driver file and i think I injected it into the WIM. I am going to verify I did inject them into the WIM. If that is the case, they are still super slow...

Jaz - I am confused because you said you update the drivers everytime a new Vmware tools comes out. I was looking for how you updated the NIC drivers for x64 WinPE. I know why the driver is really slow in WinPE, it shows 1gig, but it's lying. I imported all the drivers into the WIM, but my file copies in x64 WinPE on Vmware are still very slow. It's a driver issue, and not having loaded the correct x64 Vmware NIC driver into the WIM. ANy thoughts?

Jaz - Quick question on this topic... Where can I find the correct Vmware x64 drivers to inject into the WIM?

Nice little script If you want it to be a little more dynamic use CMD inputs like scriptname.cmd %arch% %location% %mountpoint% %driverlocation% blah.. Build that out and then let the scripts dynamically add the variable Or, switch to vbscript

Jaz - I think I know what killed this.. When I imported Dell's new Drivers, I now remember that LSI makes Dell DRAC's and therefore create's the driver files. Once I imported Dell's Driver's there must've been some conflict that caused no disks to load

J - I got good news.. Thanks for making me sane for a little.. I went back to the basics, .. Looks like I got the Cart before the horse on this one.. Before I compiled a base winPE 2.1 iso image, I decided to hack around and inject all types of drivers other drives for example, Dell Drivers and HP Drivers. I am thinking that the Dell Drivers might have screwed something up, so I need to go back to the basics and start with the base WIM and go from there. The good news is, just using the base wim, I see the drives.. WooHoo... Sorry about the chasing the tail, but I appreciate you getting me back on track and not thinking, "well, i can inject this and that and this and that and start from scratch" Just curious, did you inject the x64 drivers for vmware into your x64 Wim image and if you did, did you grab them from the latest Vmware Tools installation? If so, it's a wierd location, under win2k - x64. Did you notice that?

J - When you create the machine are you using "Windows 2003 Standard" or Windows 2003 Standard x64"