Video Screencast Help

Remotely installing winpe from local network share

Created: 25 Mar 2013 • Updated: 10 Apr 2013 | 11 comments

 

I am trying to rdeploy a winxp computer with a win7 image at a remote site (many remote sites)

We use to send and install a DOS automation package to the PC, get it to boot to DOS, map to a local share and use rdeploy to image the PC from the local share.

 

We are now trying to do the same process, but with a win7 image and now using winpe2.1.

 

winpe is too big to send to 1000 PC's over DSL links, so we want to copy the winpe installer package to the existing local share(NAS), and get the PC(s) to run the package from that local share, install winpe, run rdeploy via winpe to image PC using the local image files (on the local share), and then uninstall winpe once it has imaged and booted to win7.

 

I have most of the process kind of working, but I am now getting it as streamlined and stable as possible, as once we roll this out it HAS to work. We don't have the option to physically interact with the PC, so the process cant stop at any stage.

 

My questions:

 

1. Why is my winpe install stopping once it is installed and booted to winpe. I have not done a "Install Software Package" job in Altiris, as that did not allow me to run the package from the local share at the remote site. I have just run a script that runs in windows, copies the winpe package file from the local network share to the PC's harddrive, and just runs it (no switches). This runs the package, PC reboots and into winpe all fine, I get the mapped T drive to the express share, DAgent is found and it runs and I get a DOS CMD box with "Running Agent in console mode" the DAgent window saying "Client Record Updated" with the Exit button highlighted, and a second DOS CMD window with the progress of the "startnet.cmd" and it has completed fine with "Startup Complete." and sitting at the T: drive.

The PC is still processing my install winpe script in altiris, and stays like this forever. I cant add a reboot here as its still processing this winpe install process until it gets back to window.

I don't want to add a forced reboot into the script here, because it will do that everytime it boots to winpe, including the time I boot to winpe and run rdeploy

 

Sorry this has been so long winded. I am just trying to store the large files on the local network share at each site (winpe and image7.img) so I don't have to drag them across the network when I image the PC's.

 

Everything has to be don't remotely and without PXE, and without using large files stored on the deployment server.

 

look forward to hearing back

 

am running DS 6.9 SP4

Operating Systems:

Comments 11 CommentsJump to latest comment

BBC's picture

Hi,
We do something pretty similar, but with Remote PXE servers in the sites where the same box also holds the files under a share, from which we copy/deploy them.
About WinPE, I suggest you try this:
1. Copy the WinPE files to the client (basically, this is the Sources folder containing the BOOT.WIM and the BOOTMGR);
2. Change the MBR (under WinXP you would use i.e. bootsect.exe /nt60 c: /mbr and under Win7 to boot off a locally stored WinPE you would use a command like i.e. bcdedit /default {7619dcc9-fafe-11d9-b411-000476eba25f} where the GUID is valid for my WinPE, but could be differnt for yours);
3. perform a SHUTDOWN off the DS, but NOT A REBOOT !!
4. Auto-schedule the next job and that should run in Automation, but not DOS automation, so that the client
a) receives a WoL signal via the job;
b) can pick it up from within WinPE.

I do this for years and am driving a lot better with the solution of having WinPE on the client as this allows me to change the primary boot OS at any time and in case do an in place rebuild without data loss or having to store data off-box. I even migrate from XP (x32) to Win7 x64 using this process successfully for over a year now.

-BBC

Thomas Baird's picture

I'm going to say this just once, and wince a little as I do so...

This is one of those times I wish you'd said you were using DS 7.1.  Automation folders would have rolled out to package servers in that location, and you'd have a quick and easy way to do exactly what you want without any scripting.  This is the one SOLID advantage DS 7.x has over the 6.9 world - integration with package servers.  Even fixing the WinPE load is simple because we do it on site, so we don't send 150M over the link, only the changes.  What confuses me a little is why it boots to WinPE just when you install the partition...  I didn't think that was necessary.  maybe there's a switch that would prevent that, but my strength is 7.1 and I'm not sure about the 6.9 caveats.

Good luck though!  I'm sure you can find a way.  :D  Hopefully BBC's comments will work for you.

Thomas Baird
Private Consultant

 

APNK's picture

Hi

thanks for the replies, much appreciated.

Automation folders would have rolled out to package servers in that location, and you'd have a quick and easy way to do exactly what you want without any scripting.  This is the one SOLID advantage DS 7.x has over the 6.9 world - integration with package servers.

I'm sure DS 7.1 has many advantages, but we have almost 150 remote sites, and having a server at each site will never be an option, or I would just install a PXE server at each site.

What confuses me a little is why it boots to WinPE just when you install the partition...  I didn't think that was necessary.

I'm not either. I am not aware of any switches when running the package. I am literally running the package file from the local PC just as a standard .exe file using a "Run Script" job ( D:\WinPEx86_test.exe). It does the install in windows then reboots, boots into winpe and sits there forever. The "Run Script" job is still running. Interestingly if I delete this running job, the PC sitting in winpe will then reboot automatically. So it looks like this run script is holding the dagents attention for some reason. I can put a reboot after this run script, but it never gets to the reboot command, as it is still sitting on the run script, installing winpe.

We do something pretty similar, but with Remote PXE servers in the sites where the same box also holds the files under a share, from which we copy/deploy them.

We have only remote sites, we have a central Deployment/PXE/DHCP/DNS/AD server, but all the computers are at remote site, and each site is on its on subnet, and there are no servers at these sites. Most sites have a NAS that we use to hold the large image file, and we reimage the PC from the image on this NAS. Now we need to include the winpe files on this NAS. Some of our site do not even have a NAS, so we send them a USB with the image on it, and run the same reimage jobs, but point it to the USB rather than the NAS to find the Image.

1. Copy the WinPE files to the client (basically, this is the Sources folder containing the BOOT.WIM and the BOOTMGR);
2. Change the MBR (under WinXP you would use i.e. bootsect.exe /nt60 c: /mbr and under Win7 to boot off a locally stored WinPE you would use a command like i.e. bcdedit /default {7619dcc9-fafe-11d9-b411-000476eba25f} where the GUID is valid for my WinPE, but could be differnt for yours);
3. perform a SHUTDOWN off the DS, but NOT A REBOOT !!
4. Auto-schedule the next job and that should run in Automation, but not DOS automation, so that the client
a) receives a WoL signal via the job;
b) can pick it up from within WinPE.

This sounds promising, but I have just tried it and killed the PC. It worked fine but I stupidly stopped the rdeploy process. This means the MBR is now pointing to a location that does not exist. I have no way of recovering this PC without physically interacting with the computer. This physical interaction is what I am trying to eliminate. If I had the automation partition installed I would be able to remotely reboot it and throw the rdeploy job back at it, it would boot to winpe and try again. Once the PC is successfully reimaged it boots to windows, and only at that point to I uninstall the automation partition.

Do everythign with zero physical interaction with the PC: hard, yes, reduces my option, yes, perfect, no, but I have 150 sites with DSL connections that I need to reimage, a NAS at most of those sites. I need solid processes that allow me to retain control of the PC even if something goes wrong, to while working with upgrading windows, I need to rely on the automation boot to do all my work. So just pointing the MBR at something on the C: drive of windows is fine if everything works perfectl;y and the PC reimages nicely, but leaves no room for error, and difficult to recover from if something goes wrong.

 

Thomas Baird's picture

"having a server at every site" is... an interesting concept.  A server is a file share point, little more.  Configure an XP workstation with Package services, and voila - it's a server.  I'm assuming the limitation to 150 sites with servers is hardware, but that's not necessary.  You DO need a place to store images, and you need a way to distribute software, and package services is perfect for that.  Put Task services on it as well, and the DS components (mostly a share point) and you've a remote imaging server, even if it's running on XP.  The only caveat is the need for IIS.  :(

There may be another work around depending on IIS.  But the Automation Folders are pretty easy to manage.

 

Again, all of that is 7.1 information.  For 6.9 it's different, so I'll leave off on this.

Thomas Baird
Private Consultant

 

BBC's picture

Thomas is right here and it is not much different with 6.9 where we have plenty of remote PXE "servers" where the servers are really just Windows 7 client machines onto which the services have been installed. In addition, we have a secondary HDD in (storage is a very low cost for desktops) and store data on them and that works out even for slow links.

Hope that helps a bit further.

APNK's picture

Hi

I appreciate the input, and please don't think I am being ungratefull but I can't see how I can do this without generating work for ourselves.

The PC's at each site are all public PC's, have an identical software image on them. To make 150 of the 750 computers different in anyway from the rest just increases the workload. Differences makes troubleshooting issues longer, number of issue increases, software image variations increases means testing for different builds etc etc. And then to administor 150 Package services and Task services just adds workload. It may not be huge but (purely) remotely supporting anything is time consuming, and there are really only 2 of us that support the infrastructure hardware software inplementation etc etc, so we try not to give ourselves more work to do.

And even if it could be setup with zero workload increase and works perfectly...how then do I image those 150 PC with the package and task services and image on them? I am then still looking for the same thing I am looking for now.

b3tts32's picture

We have 225 remote sites which we're using remote pxe services from DS 6.9 on local xp/windows 7 desktops. I know you mentioned you don't want the extra administration of the 150 package services but most of the work is done up front, and if done right there's not much to manage once it's setup. We have 2 guys managing our infrastructure as well across 7,000 machines so I feel your pain. We use LinuxPE rather than WinPE and it's made a world of difference as far as speed is concerned and I'm definitely no linux guru or anything close.

 

I'd definitely recommend at least looking into it, and if you want to shoot me a message if you want more info feel free. Also, this article published by Ian Atkin has been a HUGE help! 

 

https://www-secure.symantec.com/connect/articles/leveraging-pxe-servers-transparent-image-and-software-delivery-deployment-server-6x

Thomas Baird's picture

have you called support?  I decided to go back to your original question, and I wonder - have you tried the following KB?

http://www.symantec.com/docs/TECH141958

Maybe the build you pushed out is corrupt and you have to rebuild the WAIK / PE environment.  If you are installing an embedded partition, it should reboot to WinPE, config a few things, and boot back into production - not just leave you there hanging.  Look at that article, see if maybe it can help.

Thomas Baird
Private Consultant

 

APNK's picture

woohoo enlightened

A huge thank you b3tts32,

I think you make have put me back on track. We actually use a linux package to image the PC's with winXP, as it is faster than the DOS package. We are windows here, so it was someone doing us a favor to get that Linux package working, so have been doing the WinPE thing just because thats what we know.

BUT...great news, that link you sent talked about using Tokens in the package path! I never thought of that, brilliant!

I have just tried it with a couple of different tokens, and there is a bit of an issue getting it to find files on the default hidden drives, C$, D$ etc ( \\%COMPNAME%\D$\WinPEx86_installer.exe). It does not seem to find that path. Error 53

I had a bit of a play around with the "Package distribution options" "Advanced..." options, and using the "Run package in console user session" option got it working.

This test PC is not yet joined to the domain, so may be different setting for all the PC's on the domain, but using the Token \\%NIC1IPADDR%\d$\winpex86_installer.exe got the package installing, rebooted to winpe, did its thing and then rebooted back into windows XP, completed the job.

That is exactly what I am looking for. I can now get it to do the imaging task.

I have another question now. How can I intereact with the computers token info. Each PC has a swath of data associated with it, and going into the properties of the PC you can see lots of them. But if I wanted to add a "Site" to each PC (under Location), how can I add this into that field in Altiris for all our PC's? It would need to be dynamic, or maybe I could import it in from file.

And is there a way to export data from there.

Many thanks b3tts32

b3tts32's picture

I'm glad you were able to make some progress! I know how frustrating these things can get. 

 

Just a few things to note..

 

We're still using LinuxPE to deploy our Windows 7 machines, the reason it doesn't work by default is the 100mb hidden partition. We got rid of that partition and it's been smooth sailing ever since.

 

I've always tried to make it a point to add a subfolder below the default admin share and share that one out so you could lock down permissions a bit more. Are you copying the WinPEx86 installer from the "Site" pc at each site? If so, you could do something like \\%SITE%\Deploy and just keep it dynamic. You could map the \\%SITE%\Deploy share in your boot disk creator and as long as your image name is the same across the board you would just need one script/imaging task. Sounds like you may have this figured out already but I thought I would mention it.

 

You could update the Site token a few different ways, but it's all going to come down to SQL. There's a built in stored procedure that updates this for you, you would just need to pass the info you want populated. The easiest way would be to call the stored procedure from a run script task directly from the DS as Ian mentioned in his article. 

 

 

REM %#*"{call ins_location( %ID%,'10.0.1.100' ) }"%

This would update the site token with 10.0.1.100. 

 

The "tricky" part would be updating this dynamically, and with 150 groups you probably don't want to manually do these all. This can be scripted but you would need a source record somewhere that held your locations and the IP/ComputerName you wanted populated. You could do this with powershell and import your source (csv or excel) then parse and return your info. Once you have the correct info returned you'd just pass it to the above stored procedure. 

 

I could put something together for you, I'd just need a bit more info. Sorry for being so long winded.. haha I hope this makes sense.

APNK's picture

We have a NAS at each (most) site with an "Images" share on it. I store the large image file on this share, and will now be storing the large(ish) winpe install package on this share at each site.

I have been testing by mapping to this share and copying the winpe package to the PC then running it from the location I copy it to C$, D$ D:\winpe\. It doesnt matter where on the PC as its about to be reimaged. 

Each site has its own subnet, and each NAS is subnet.240 so using the PC's IP address I can dynamically map a drive to the NAS using a small bit of (good old) DOS

 

REM Map local NAS to R:
for /F "usebackq tokens=14" %%i in (`ipconfig ^| find /i "IPv4"`) do set MYIP=%%i
echo %MYIP%
:: Split IP into Separate Octects
for /F "usebackq delims=. tokens=1-4" %%i in (`echo %myip%`) do (
set GIPO1=%%i
set GIPO2=%%j
set GIPO3=%%k
set GIPO4=%%l
)
set NAS=%GIPO1%.%GIPO2%.%GIPO3%.240
net use R: /DELETE /Y
net use R: \\%NAS%\Images /USER:%NAS%\admin password

I just need to straighten out the unattend.xml file and I think I might be home in time for dinner. I might revisit this to get things like the SITE updated etc, would be a nice thing to have, but not a priority at the moment.

Thanks so much for you help b3tts32, very much appreciated.