@george1421 I’ve also used a custom vb program and the unattend.xml first run feature to auto login to the workstation right after imaging and then run the vbscript to move the target computer from a build up OU to the proper OU. Then reboot. I have the fog postinstall script update a parameter that is passed to the vbscript during imaging. While I didn’t write this script http://blog.coretech.dk/jgs/vbscript-move-computer-object-to-another-ou-via-command-line-parameter/ it is crazy similar to the one I wrote. It would have been nice If I found this one first to save me some grief.

The only caveat here is that this script must be run as a user that has domain move computer rights.

@Tom-Elliott Nice - thanks!

@Tom-Elliott Yeah, I thought it would come down to naming the snapins appropriately. In our case, I think most like to know what they’re signing up for. As such, I’ll just create a document for them to follow and then answer any questions that do come up from it.

Thanks for the help and assistance!

I use a slightly alternative method personally, where I run the powershell command from a batch script, which requires a slightly different approach.

Example:

powershell -Command "& {Set-ExecutionPolicy RemoteSigned; Import-Module PSWindowsUpdate; Get-WUInstall}"

Thanks, Wayne. I’ll test this out shortly and report back my findings 🙂

@Wayne-Workman Yep, I already learnt that one the hard way 😛
Thanks!

@Wayne-Workman Perfect - thanks for this!

@george1421 +1 for a wiki page. This is really useful stuff and I only found out about it when coming onto the forums and talking with George. Without the forums, I wouldn’t have ever found this out/get it working.

@Wayne-Workman Indeed - many thanks for your help 🙂

@RobTitian16 If you like, you can use my batchfile for this. It should work across all Windows ADK as far as I know

@echo off rem The fileserver IP set FILESERVER=192.168.1.155 rem Share on the fileserver. set SHARE=INSTALLERS\ISOFILES\0-WINPE rem Username for the share set SHAREUSER=root rem Password for the share set SHAREPASS=root rem amd64 or x86 set ARCH=amd64 rem Path to hold working files. Needs about 500MB of free space. set PEPATH="c:\winpe_%ARCH%" rem ########################################################## rem Don't edit anything below here rem ########################################################## echo Creating the PE image call copype.cmd %ARCH% %PEPATH% > NUL echo Mounting the image dism /Mount-Wim /WimFile:%PEPATH%\media\sources\boot.wim /index:1 /MountDir:%PEPATH%\mount /quiet echo Adding commands to the startup script in PE echo. >> %PEPATH%\mount\windows\system32\startnet.cmd echo ping %FILESERVER% >> %PEPATH%\mount\windows\system32\startnet.cmd echo net use z: \\%FILESERVER%\%SHARE% %SHAREPASS% /u:%FILESERVER%\%SHAREUSER% >> %PEPATH%\mount\windows\system32\startnet.cmd echo z: >> %PEPATH%\mount\windows\system32\startnet.cmd echo z:\64.bat >> %PEPATH%\mount\windows\system32\startnet.cmd echo Creating the pxeboot directory mkdir %PEPATH%\pxeboot > NUL mkdir %PEPATH%\pxeboot\Fonts > NUL copy /y %PEPATH%\mount\windows\boot\Fonts\*.* %PEPATH%\pxeboot\Fonts\ > NUL copy /y "%WinPERoot%\%ARCH%\Media\Boot\boot.sdi" %PEPATH%\pxeboot\ > NUL copy /y "%WinPERoot%\%ARCH%\Media\Boot\BCD" %PEPATH%\pxeboot\ > NUL echo Unmounting the image dism /unmount-Wim /MountDir:%PEPATH%\mount /Commit /quiet echo Optimizing the image imagex /EXPORT %PEPATH%\media\sources\boot.wim 1 %PEPATH%\pxeboot\boot.wim > NUL echo. echo All the files you need for your PXE server are in: %PEPATH%\pxeboot\

Adjusts the variables as needed.

Then you can have a 64.bat at the target location, which you can edit at any time to for example create a selection menu for different setup.exe files

@Wayne-Workman Not sure, dynmically sized hard drives can cause all kinds of issues though, one of them being that you only get the space used when your image is deployed and you’re unable to expand it in Windows.

@RobTitian16 Just seems to have been a slow network day I guess as it’s running through fine now at 3GB/min 🙂

@Sebastian-Roth Updated to fail in the case we can’t create the mount directory OR the partition cannot be mounted. Because I write the data to a log, I am also able to output the “reasoning” behind the failure too to try to help people hone in on the issue.

@RobTitian16 said in Issues Updating to Latest Version of Trunk:

Hi everyone,

I’m currently getting the following error when trying to update to the latest version of trunk:

0_1466075064417_Capture.PNG

It seems to be stuck on preparing package manager now as well… should I try updating later? Is this a known issue with the latest version?

Hi, OS ?

Thanks for the help! Somehow after increasing the size of my FOG server hard drive, it went through perfectly fine 🙂

@RobTitian16 That’s what I’ve done, yes. I discovered, by luck, that not appending anything to memdisk works for certain ISOs. I use Parted Magic frequently, so I was happy to get it working. I’ve never seen this documented anywhere…glad you’re working!

@Quazz I had to change the hard drive as it wasn’t playing ball, but upon doing so even that one messed me around and failed to mount the partition. It updated the database and then removed the job from the list of active tasks. I removed the host from Fog and re-registered it, thus fixing the issue. I was able to upload the image successfully after that 🙂

Thanks for the help and suggestions!

@Wayne-Workman That’s solved it! Thanks a lot for your help 🙂

@george1421 Upgrading to trunk has resolved this issue - thank you! 🙂