Sysprep & Drive Letters

[jack0w]

After the close you could try setting the objects to nothing then adding a wait period before trying to access it:

Set objFSO = nothing
Set objOutFile = nothing 
WScript.Sleep(5000)

Set objShell = CreateObject ("WScript.Shell")
objShell.Run "diskpart /s C:\diskpart.txt > c:\Logfile.txt", 6, True

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objOutFile = objFSO.OpenTextFile("C:\diskpart.txt", 8, True)
If objFSO.FileExists("C:\diskpart.txt") then objFSO.DeleteFile "C:\diskpart.txt"

Also, is there any specific reason why you are using objFSO.OpenTextFile rather than objFSO.CreateTextFile ?

No particular reason for this, would it be better to use CreateTextFile? I'm still trying to teach myself when it comes to vbscript!

Just tried that and it seems to do the trick! Thank you very much for your help on this!

[SYNACK]

No particular reason for this, would it be better to use CreateTextFile? I'm still trying to teach myself when it comes to vbscript!

Just tried that and it seems to do the trick! Thank you very much for your help on this!

CreateTextFile is the more standard way of doing this kind of thing as it automatically creates the file without extra command options, the OpenTextFile method is generally usually used more for reading out or appending to existing test files. Because OpenTextFile was used it needed the 'true' appended to the end to tell it to create the file if it did not exist. Where as CreateTextFile would have just needed the filename passed to it.

Your code is a perfectly valid way of doing it I had just not come accross another example where OpenTextFile was used to create the file and so suspected it may have been causing trouble. Good to hear that you got it working.

[jack0w]

Still a bit stumped on this, the script works perfectly - I've tested on several computers myself. However when it runs after sysprep (either through the GuiRunOnce or Cmdlines.txt tried both ways!) if you read the log file it says the drive letter was successfully changed, however when you actually go and take a look at the virtual cd drive it has still reverted to the first available drive letter!

Tearing my hair out with this, so any suggestions would be much appreciated.

Cheers

[powdarrmonkey]

I would second USBDLM. See the 'Letters by Device ID' section in the help file. You can find the device ID in Device Manager.

[SYNACK]

Still a bit stumped on this, the script works perfectly - I've tested on several computers myself. However when it runs after sysprep (either through the GuiRunOnce or Cmdlines.txt tried both ways!) if you read the log file it says the drive letter was successfully changed, however when you actually go and take a look at the virtual cd drive it has still reverted to the first available drive letter!

Tearing my hair out with this, so any suggestions would be much appreciated.

Cheers

It sounds like whatever process is resetting the drive letters to the first available is running after the GuiRunOnce and Cmdlines.txt sections have executed. The only thing that I can think of to deal with this is somehow running the script later in the imaging process on the first logon afterwards by scheduling the script to run with appropriate credentials using the schtasks.exe app in the GuiRunOnce or just set it up to run on every startup.

[jack0w]

I would second USBDLM. See the 'Letters by Device ID' section in the help file. You can find the device ID in Device Manager.

I'm currently using USBDLM for flash drives, however I can't seem to get it to work for the virtual cdrom drive. I've tried it with the friendly name and the device id in the ini file but to no avail. Have you managed to get USBDLM to work with non-usb devices?

[s69]

Try

objShell.Run "cmd /c diskpart /s C:\diskpart.txt > c:\Logfile.txt", 6, True

[azrael78]

It's also possible that when you run the command, sysprep (or a process within) is resetting the drive letters.

Perhaps an easier way would be to stick it in RunOnce for All Users, means sysprep shouldn't run it and it should run AFTER sysprep completes.

However it's also possible that diskpart may not have permission to do what you are asking, which it may well not do with my suggestion above.

It's tricky - had a similar situation where a cloning disaster caused drive C: to appear as D: and A: to appear as C: - oh yes, that was fun.

Alot of digging for certain registry keys solved it.
Let me see if I still have it...

Okay... on a PC that works as expected.

Under HKLM\System\MountedDevices is a bunch of keys with volume GUIDs in them.

There are also ones called DosDevices.

Export that registry key and use a text editor to compare - much easier.

Open up the registry file in notepad.

The values for DosDevices should match the Volume{GUID} - so in your case, look for the following:

\DosDevices\K:

Look at the value data for this and find the same one in the \??\Volume{GUID} bit.

Using notepad search, you can quickly find the one you want - now you want to copy the bits of the keys you want (the single Volume{GUID} and DosDevices entries that match) into a seperate .REG file (make sure you keep the first 2 lines of the original export file).

Import this on a PC that didn't have the right letter and reboot.

Hopefully - albeit a long-winded way, but it should help.

Az

[jack0w]

Cheers for the replies people!

I've managed to get this one working now, using the original vbscript I've created a new OU in AD called Imaged Computers, set Ghost to create the Computer Account in this OU, that way on first boot after joining the computer to the domain the script is run under the System account as a Startup Script.

This seems to do the trick, not sure why it wasn't running to start with but hey, at least its working!!

Thanks for everyones help and suggestions with this.

[FN-GM]

Cheers for the replies people!

I've managed to get this one working now, using the original vbscript I've created a new OU in AD called Imaged Computers, set Ghost to create the Computer Account in this OU, that way on first boot after joining the computer to the domain the script is run under the System account as a Startup Script.

This seems to do the trick, not sure why it wasn't running to start with but hey, at least its working!!

Thanks for everyones help and suggestions with this.

Did you use the exact same script as the first page? Please can you post your full script. I am having the same problem as you.

Thanks

Z

[jack0w]

This is the script I ended up using:

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objOutFile = objFSO.CreateTextFile("C:\diskpart.txt")

On Error Resume Next
strComputer = "."
Dim strDriveLetter
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_CDROMDrive")
For Each objItem in colItems
    If objItem.Name = "Avantis Open CDMVD001 SCSI CdRom Device" Then objOutFile.WriteLine "Select volume" & " " & objItem.Drive
Next
objOutFile.WriteLine "assign letter=K:"
objOutFile.Close

Set objFSO = nothing
Set objOutFile = nothing 
WScript.Sleep(5000)

Set objShell = CreateObject ("WScript.Shell")
objShell.Run "diskpart /s C:\diskpart.txt", 6, True

I dropped the script into the netlogon folder, and assigned it as a Startup script on an OU which I put all computers that have been imaged into.

[User3204]

I uninstalled the Avantis client.. it was easier... but since the hardware was failing this summer too..
'Course our trouble would be that we have 3 avantis drives (or we did before I dumped the thing).

If you use the older 1.31 version of the software, it doesn't work the same way, and actually remembers the settings after a sysprep.