Br4tt3

Hi guys! I have been running x86 versions of WinPE and 2003SP1 installations, but I am trying to move into x64 environments.... so I have rebuilt my WinPE based on x64 Windows 2003 SP1 source media, which is working, I then kick of the Windows2003x64 installation from within WinPE with the following command: Start /wait C:\Progra~1\<company>\amd64\winnt32.exe /s:C:\Progra~1\<company>\amd64 /syspart:c: /tempdrive:c: /unattend:C:\unattend\standard.txt The installation kicks off but after copying some files, it returns the following error: An error occurred copying file w_isdel.exe to c:\$win_nt$.~ls\i386\w_isdel.exe If I check the amd64 directory on the RTM CD, no such file: However, there is a file named like that in the i386 folder which makes me wonder? Should I copy the amd64 or the i386 down locally before running x64 installations? x86 on win2003 corresponds to the i386 folder, I built my new x64 WinPE using the source files within the amd64 directory.... then again, it is somewhat confusing that they call it winnt32.exe when from what I understand u actually kicking of a 64 bit install... Anyone have any insights on how to launch x64 installations from within WinPE? Please enlighten me...

Thanks man....

Forgive my ignorance, but I dont see any explenation in the .chm files for amd64/wow64 or x86..... maby something obvious, but I cant see any info on it. For example, if I add the component: amd64_Microsoft-Windows-International-Core-WinPE_x.xxxxx and then press F1, I will get the generic description on Microsoft-Windows-International-Core-WinPE and no reference to what the pre architecture info amd64/wow64 or x86 means in this scenario..... :| Maby it does not mean anything, but still I wanna read about it. If someone know a search param in the .chm where I could find that info, please respond! Thanks...

I had a similar problem, and a guy in this forum to told me to change it from: <DiskConfiguration> <WillShowUI>Never</WillShowUI> <Disk> <CreatePartitions> <CreatePartition> <Order>1</Order> <Type>Primary</Type> <Extend>true</Extend> </CreatePartition> </CreatePartitions> <DiskID>0</DiskID> <WillWipeDisk>true</WillWipeDisk> <ModifyPartitions> <ModifyPartition> <Active>true</Active> <Extend>true</Extend> <Format>NTFS</Format> <Label>SYSTEM</Label> <Letter>C</Letter> <PartitionID>1</PartitionID> <Order>1</Order> </ModifyPartition> </ModifyPartitions> </Disk> </DiskConfiguration> into: <DiskConfiguration> <WillShowUI>Never</WillShowUI> <Disk> <CreatePartitions> <CreatePartition> <Order>1</Order> <Type>Primary</Type> <Extend>true</Extend> </CreatePartition> </CreatePartitions> <DiskID>0</DiskID> <WillWipeDisk>true</WillWipeDisk> <ModifyPartitions> <ModifyPartition> <Active>true</Active> <Extend>False</Extend> <Format>NTFS</Format> <Label>SYSTEM</Label> <Letter>C</Letter> <PartitionID>1</PartitionID> <Order>1</Order> </ModifyPartition> </ModifyPartitions> </Disk> </DiskConfiguration> and the explenation was that since I already expanded it in the "CreatePartition" section, no need to do it in the "ModifyPartition" section.... worked for me! Hope it helps...

The actual machine account object creation from within a WDS setup is done from the .xml file, pretty much as unattended join to the domain, as if installed through CD or DVD. So it the issue, where it would be tricky to install workgrouped computers using RIS, is eliminated.

So, I started out with an x86 image and an answer file for that x86 based image. Now that I am trying to get an x64 image answer file in place, I dont understand what the diffrent subcomponents mean and how they correspond to eachother! When expanding the components tree in the WSIM, u get the following options for some components: 1. amd_64 2. wow_64 3. x86_64 Any one had any expierence on how to read more abouth these features? Are the x86 settings relevant to the x64 installations as well if there are no corresponding settings within amd64 or wow64 sections?

Hi! I actually asked MS the same questions, cause we also make heavy usage of the variable functions within the old .osc screens of RIS and we wanted to move that functionality into the WDS environment. The answer from MS was: Alt 1: Write some C/C++ code that will use the supplied API's for WDS, released from MS to enable third party companies to write plug-ins. That sounds pretty nice, but I dont know how to code C/C++, or.... Alt 2: Produce your own .hta application that can be run prior/post to the WDS client that could gather the required information which then could be used later on in the installation process. This is the way that I will try as it is much easier, even though not so smooth as real compiled code! Once done, I can drop u an example of the .hta if u want to! But dont stay up, it is not due for some time...

Let's see here... did u try to capture MS DOS 6.2 into a .wim file format or? then loaded it onto the WDS server? Let's start by saying that I have not tried it, but I doubt that it will ever work!! The WDS accepts two kinds of images, boot and install images, both must be in the form of a .wim file, so far so good! Then, for boot images, a requirement is WinPE 2.0, and for install images, the image that is to be captured into a .wim format must have been sysprep:ed prior to the capture! That would support win2000, xp, 2003 and Vista but not MS DOS as it does NOT know what sysprep is.... DOS is dead, MS WinPE r0x...

Just got to the point where I wanna try out adding drivers and tools to the unattend install of Vista using the DataImages option. According to the documentation, they wanna specify the location of the dataimage.wim file using: \\networkshare\share\dataimage.wim + domain, user and pass ? I am somewhat confused, as they normally point an UNC path as: \\server\share\path_to_wim_file.wim I tried the last alternative but with limited success. The .wim is working if I apply it manually using imagex.exe but not from the WDS .xml file (do you have to add the imagex tool into the WinPE boot image?). Also, I can open the UNC from full Win32 using the same security context as the credentials specified in the .xml file. <Path>\\server\share\DataWIM\Mainhook.wim</Path> <MetaData wcm:action="add"> <Key>/IMAGE/NAME</Key> <Value>Mainhook</Value> </MetaData> Keep trucking...

Me wrong, working now.....

Tried it, works so far with some exceptions: 1. The drive letters are still messed up, the first primary drive still gets C: assigned, should be G: 2. The next partition (logical) gets assigned E: (?) even though I told it to use C: Thanks for your response, I still dont know what the actual setting does, cause when reading the .chm file the most logical value should be True (as in fill up the remaining empty space to the drive). Thanks again, man...

What if I wanna split my disk 0 into the following desired configuration using WDS? Desired config: Partition 1: Active, primary, size 3 GB and drive letter D: Partition 2: Primary or extended with a logical drive, remaining drive space, drive letter C: I wanna get this in place, so that the Vista boot files are placed on the D: drive (active) and the remaining files on the C: drive, which would be the remaining Vista operating system. I wanna get this in place so that we can run BitLocker.... my .xml fails when trying to deploying this configuration, and no luck so far: XML: <DiskConfiguration> <Disk wcm:action="add"> <DiskID>0</DiskID> <WillWipeDisk>true</WillWipeDisk> <CreatePartitions> <CreatePartition wcm:action="add"> <Extend>false</Extend> <Order>1</Order> <Type>Primary</Type> <Size>3000</Size> </CreatePartition> <CreatePartition wcm:action="add"> <Extend>true</Extend> <Order>2</Order> <Type>Extended</Type> </CreatePartition> <CreatePartition wcm:action="add"> <Extend>true</Extend> <Order>3</Order> <Type>Logical</Type> </CreatePartition> </CreatePartitions> <ModifyPartitions> <ModifyPartition wcm:action="add"> <Order>1</Order> <PartitionID>1</PartitionID> <Letter>H</Letter> <Label>VistaBoot</Label> <Format>NTFS</Format> <Extend>false</Extend> <Active>true</Active> </ModifyPartition> <ModifyPartition wcm:action="add"> <Order>2</Order> <PartitionID>2</PartitionID> <Letter>C</Letter> <Label>BitLock</Label> <Format>NTFS</Format> <Extend>true</Extend> <Active>false</Active> </ModifyPartition> </ModifyPartitions> </Disk> <WillShowUI>Never</WillShowUI> </DiskConfiguration> If I perform the same manual steps (using diskpart) from WinPE 2.0 and then kick of the installation, it works, just a matter of xml entries that seems to go wrong! The image goes to partition #2 with the following parameters: <WindowsDeploymentServices> <ImageSelection> <InstallTo> <DiskID>0</DiskID> <PartitionID>2</PartitionID> </InstallTo> </ImageSelection> </WindowsDeploymentServices> Any thoughts? or even better, solutions to this one? Thanks in advance!

Hi! I am trying to digg into the Vista deployment documentation, which is pretty stiff.. and I got some questions! 1. Does all the entries that are listed in the cmh files (unattend.chm) correspond to the diffrent deployment techniques? I mean, are the same entries valid when installing using WDS or installing via a DVD? I cant see that there are any references in the help file which clearly points out if they only are valid for let's say WDS... 2. When using WDS; should one "brake" out the WinPE phase entries into a single boot answer file or is there a best practies to include all settings into one single .xml file that runs the whole setup expierence? In our corp, I would like to have one single boot image (with one single boot option xml file) and then multiple installation images with one single .xml file for each one.... 3. Dependencies between the values! Are there any? Cause I get the general picture where u add one component and the supply the values for configuration. However, some of my configuration settings gets applied while some does not, is it a dependency or is it that the input params are incorrect? My options that does not get applied deals with "data images" that does not get applied when installing Vista from my WDS server! Lots of questions, still hope some of them makes sense...

Hi! As from ITForum 2006 in Barcelona, and the guy that is actually writing BDD (M.Niehaus) the BDD2007 will reach RTM version at the end of November as they had to try some "stuff" before releasing it! I guess there is a coupple of days left until BDD comes of the shelfs, until then, WDS and Vista, WinPE 2.0 and WAIK is up for grabs!

Awsome, MS webby went totally nuts when I searched for the WAIK, thanks a bunch man for the link! Vista, WinPE, WDS, here we go...

Hi! U can prolly fix the autologon features from within the .sif file but I use the registry to add the values to the installation: Key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon 1. Value: (Alt)DefaultDomainName (REG_SZ) with the NetBIOS name of ur domain, e.g; mydomain 2. Value: (Alt)DefaultPassword (REG_SZ) - specify the password of the service account for example 3. Value: (Alt)DefaultUserName (REG_SZ) - specify the serviceaccount user name 4. Value: AutoAdminLogon - Yes/No or even better: http://www.windowsnetworking.com/kbase/Win...maticLogon.html Hope it helps...

For every time I reboot the server, I can change the driver signing configuration once via the script.... so it works, every time I boot the machine. Comparing that to the GUI, I can change the settings as many times I want to without a reboot... Any ideas?

Same thing, diffrent names in diffrent versions of the beta release. According to my MS pam, another supplier had contacted them and said; "Hey, we already got a tool named ximage.exe" so they changed it.... that or they felt better using imagex.exe....

Agree, unless u do ur own version of it.... just a question, the RIS and DFS solutions, does that work out well with SIS (Single Instance Storage)? I have never tried it and maby u can shead some light on it?

I already like ur end users more and more.... they remind me of mine! My guess is that u have to develop something that corresponds to a home built SMS 2003 OSD kind of thing like we have done, or buy MS 2003 OSD and SMS with all tha bells and whissles!!! U might go bankrupt while ur at it but it works smoothly... F12 does not meet the requirement, as u need to manually press F12. However, SMS 2003 with OSD does not either meet this requirement until the first time the PC has obtained a SMS agent... then it can be managed and reinstalled remotely! Ghost, dunno much about it but I dont think u can do it unattended unless wrapped in tons of .vbs and an intermediate boot OS such WinPE or BartPE! And if u r already into building that, then u dont need to worry about SMS, but then ur on ur way to building a simple OSD!

Then, my question is: Do you have to be able to remotely launch the actual reinstall of the clients or is it more important to be able to deploy the installation method? For example, is it oki to have the end users boot their machines and then press F12? If u must be able to deploy machines without being physical at the machine, then I guess ZTI/SMS 2003 with OSD! If this is not a criteria, then the easiest way to do it is to write a little .vbs which will do it for you (outlined below): 1. The script will have to execute the sysocmgr.exe which can be used to install or to uninstall native Win2003 components, for example the RIS component in Win2003. U specify the sysocmgr.exe to point to a .inf file which contains the component to install, for example: [Components] reminst = On 2. Once u have done this, the machine will have the RIS component installed. Now it is time to configure the server components, which is easiest done via running rissetup.exe /u <answer file> if I remember correctly. At this time, the script can also do several other configuration parameters to be used within the RIS deployment. 3. I also suggest that u will only install and configure the RIS component, each image to be added, is a simple copy sequence which is preferable trough .msi rather than .vbs. The nice part of this approach is that since it is a native Windows component, u dont have to download and transfer whole image(s) each time a client needs to be reinstalled, rather, just send the "small" .vbs script over the WAN and the script can access it's own source file local to the machine and begin the installation from there..... saves bandwith! And no licenses to Symantec for each ghost, just utilize the things that u have already paid for with the Win2003 license.... For the language question of the OS, could u not use MUI's? have one base OS installed on all clients (English) and apply the correct MUI for that language to the specific criterias? such as domain, OU, naming convention or something else? this would work out for Office as well.. Maby?

I can only encourage u to run it from a .vbs script instead.. easier, better and more efficient IMHO, example: Option Explicit Dim Input, Command, WshShell Set WshShell = WScript.CreateObject("WScript.Shell") Input = InputBox("Application .exe name to run") MsgBox ("You entered: " & Input) 'Exec the application of choice or whatever... ExecApp(Input) '****************** '* Execute Function '****************** Function ExecApp(pstrCommand) Command = WshShell.Run(pstrCommand, 0, True) End Function Try for example: calc.exe and it will be launched.. u can then replace that with reg load or something else...

I hated disk imaging before... static and not so generic when dealing with loads of diffrent machine, especially when it comes to HAL things... of course, Vista will remedy that for us! Anyway, to answer ur question: ZTI comes from the BDD concept, however, running RIS/GHOST does NOT qualify for ZTI, those are included with the LT (light touch) concept I think, and dont shout @ me, this is MS! I use the following things: 1. I build my WinXP SP2 / Win2003 SP1 images using BDD 2.5 which results in a .wim image which I then can use in any way... more or less a syspreped image. Of course those are HAL dependent. 2. Once here, I have a WinPE 2.0 image which I have built into a .msi module which I can deploy through my distribution mechanism, which is NOT SMS but a "home built thingy". I install the .msi on the desired client(s), the module will replace boot loader files and place the WinPE .wim file on the harddrive of the client, reboot the machine, run WMI scripts that determine the HAL of the machine, parse it into a image file name, fetch it from a UNC path and then apply that image using imagex.exe 3. Nice part for me is that I can do it from my admin console, which does not require me to walk over to the machines and press F12. 4. Downside, this can only be done on already installed and manageable machines, bare metal installation still has to be done using RIS/WDS which is also the case when it comes to the MS concept using SMS 2003. Looking forward to BDD 2007 / WinPE 2.0 / WDS and Vista...

Hi! We are playing around with installing backup exec unattended which is a mess... anyway, one of things we got in front of us; installing drivers to the tape devies unattended. This is somewhat of a problem as, our setting of the Win2003 servers are set to "Warn" when it comes to driver signing options.... to tackle the issue we have done the following: 1. written a vbs file that executes secedit.exe 2. secedit the parses an .inf file which we produced with the "Security Templates" MMC... which looks as below! [Unicode] Unicode=yes [Version] signature="$CHICAGO$" Revision=1 [Registry Values] MACHINE\Software\Microsoft\Driver Signing\Policy=3,0 And the secedit command looks as: cmd /c echo y | secedit /configure /db "C:\Program Files\<company>\Logs\WARNBUTINSTALL.sdb" /cfg "C:\Program Files\<company>\Security\WARNBUTINSTALL.inf" /overwrite /log "C:\Program Files\<company>\Logs\WARNBUTINSTALL.log" /verbose The script works the first around, but once u have "disabled" the check and then turned it on again, there is no way in h*** to set the config back to "SILENT SUCCEED"! So, if we wanna be able to do this multiple times, what wrong with it? Found some info on this scenario from guys that wanted to pack stuff with unsigned drivers but with no luck..... I know that it is no a good idea to alter only the reg values, rather run the secedit command to have it switched, but then again, I wanna be able to turn on and off multiple times....

Sorry, I dont know french but I think there is something wrong with tha link....