Network Share install - white screen on reboot

[diamond]

Hello everyone,

I've been running WPI for several years now, and with the recent upgrade to 7.70 have developed a problem with my existing config (where no problem previously existed).

Basically, it's called from a mapped drive letter that is mapped right after RIS setup. Everything runs fine until I have a command that requires a reboot.

after the reboot, the installer.hta comes up to a white screen, and looking at the command prompt I notice that the network drives are not mapped. The script that maps the drive letters prior to WPI initially running works great, and use the following syntax (to prevent the 'did you use persistent' questions. )

net use S: \\server\share "password" /u:domain\username /persistent:yes

Obviously, it's not as persistent as it seems, but even trying to run a reconnection script following the reboot does not seem to do anything, even if the previous script copies the reconnect.cmd to the local disk first.

Any ideas why this would all of a sudden be a problem where it wasn't before?

Please note that http://www.msfn.org/board/reboot-then-map-...ll-t126048.html is something I posted similar quite a while back, after speaking with Ritter at that time I ended up taking out my code hacks and doing registry adds instead, in case someone stumbles across that old topic.

Any help would be appreciated!

Diamond

Edited November 13, 2009 by diamond

[mritter]

I did some thinking on this, I don't see any reason it should fail. The reboot code has not been changed. Are you using the new wpi.exe launcher? I don't know anything about RIS systems so can't offer any real advice.

I have thought about adding {REBOOT_LD}, reboot load desktop, so after a reboot it will wait until the desktop is loaded before WPI continues. That should allow the drive to be mapped again properly.

This idea was mainly to load the user account for reg edits and such. Then you could do a regular {REBOOT} if wanted to and continue installing before desktop is loaded (normal way).

[diamond]

I did some thinking on this, I don't see any reason it should fail. The reboot code has not been changed. Are you using the new wpi.exe launcher? I don't know anything about RIS systems so can't offer any real advice.

I have thought about adding {REBOOT_LD}, reboot load desktop, so after a reboot it will wait until the desktop is loaded before WPI continues. That should allow the drive to be mapped again properly.

This idea was mainly to load the user account for reg edits and such. Then you could do a regular {REBOOT} if wanted to and continue installing before desktop is loaded (normal way).

I've tried using both the old wpi.hta as well as the new wpi.exe file, both with the same results (which I suppose is a good thing from a programming standpoint. ), Going back to the 'old ways', I've re-hacked the installer.js file and it does seem to remap it; however, in doing so it also wants to load the desktop before starting, causing other problems with the build.

Due to the nature of my setup, the RIS part should only matter on the reboot, as I'm not doing an image load in RIS/WDS, but instead doing a unattended install of windows with driverpacks [which allows for portability between machines as it's not a static image for a single machine]. The only change from the planned and intended use of WPI in this case are two things:

1. The program is called from a drive mapping (or UNC mapping if you did it that way) instead of being on the media itself. Here's my runonceex.cmd that's been in use for so long

@echo off
SET KEY=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx
SET PP=
REG ADD %KEY% /V TITLE /D "Installation" /f 
REG ADD %KEY%\000 /VE /D "Driver Detection Install and Cleanup" /f 
REG ADD %KEY%\000 /V 1 /D "%SystemDrive%\DPsFnshr.exe " /f 
REG ADD %KEY%\002 /VE /D "Post Installer" /f 
REG ADD %KEY%\002 /v 1 /D "%SystemDrive%\map.cmd" /f
REG ADD "HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main" /V "Disable Script Debugger" /T "REG_SZ" /D "no" /F
REG ADD "HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main" /V "DisableScriptDebuggerIE" /T "REG_SZ" /D "no" /F
REG ADD %KEY%\002 /V 2 /D "G:\installs\netinstall\wpi\wpi.exe " /f

As you can see, you get a 'standard' driverpacks finisher, then it runs map.cmd, which is just what you think it is - it maps the drive letter. From there we do the office fix and then launch wpi.exe from the network share. This part (without the remap hack) works great, though it has suddenly started going ahead and loading the desktop without waiting for WPI to finish, causing WPI to be in a smaller window than full screen, regardless of the fact I have 'Load Desktop before WPI starts' unchecked.

After it goes through some of the installs, I have an option that runs a simple batch to install some 'standard' things, like .NET and IE8. It goes through the .NET files, a few hotfixes then copies a reconnect.cmd file to the C:\ of the local machine. That batch ends and I issue a {REBOOT} command, then the next command is for "C:\reconnect.cmd", which should execute locally to reconnect the drives.

A good point this brings up is whether WPI wants to run any of it's files from %WPIPATH% prior to launching the next command after a reboot, as that would help explain why without modification I get a blank-screen installer windows after reboot, as it is trying to launch a network copy before it is connected to the network.

You'll have to forgive me as I've never really taken the time to really study your code to see the order of operations, as the program has always done a great job of working and I can't say it's ever really been a needed thing.

Finally, I know from other posts that you are trying to get more penetration into larger business market segments, and I'd like to say that I've been successfully using WPI here for several years and it's done a great job for us with a little elbow grease to get it working right originally under our RIS/WDS environment. Thanks again you two for making such a darn useful program!

Diamond

[mritter]

It could be some new feature I added that is causing the hang. It could be the internet check. I will email you a debug beta today.