Posts made by pauleb

@DBCountMan Thanks for the clarification! I see your point. Your option is quite more straight forward. The benefits left for using ODT are the lower bandwidth use (with our 100 Mbit internet) and configuration options.
It’s great that there are multiple options!

@DBCountMan

Thanks for the update. Nice to know that this is also working.
My searches just showed using the office deployment tool and since I couldn’t be sure, that there is no user / license specific information in the setup - file and I don’t want to get into licensing issues with Microsoft I did not even try this.

@DBCountMan
Thanks for your feedback, I am not sure what OfficeSetup.exe file you are using.

I wanted to configure Office on the fly when installing and update configuration. Therefore I preferred to use the solution offered by Microsoft via the Office deployment Tool and to create a configuration with the Office Customization Tool. Therefore I went with @rodluz 's solution.

@rodluz Thanks a lot!

Your script is working flawlessly!

Since it is doing more or less the same as mine with the difference, that you execute the setup from the mounted drive I also tried adapting my batch script.

It seems it also works when the executable is ran from the temporarily mounted drive.

net use z: \\truenas\MS365 /USER:Guest /PERSISTENT:NO
z:\Setup\setup.exe /customize z:\Setup\MS365-config-64-bit.xml
net use z: /DELETE

and changing my configuration .XML file to:

<Configuration ID="5c579236-99be-41f4-ba55-91c6e3c0e212">
  <Info Description="Test" />
  <Add OfficeClientEdition="64" Channel="Current" SourcePath="Z:\x64\" AllowCdnFallback="TRUE">
    <Product ID="O365ProPlusRetail">
          <Language ID="de-de" />
          <Language ID="en-us" />
        </Product>
  </Add>
  <Updates Enabled="TRUE" UpdatePath="Z:\x64\" />
  <RemoveMSI />
  <Display Level="None" AcceptEULA="TRUE" />
</Configuration>

Since nothing but the location of the executable and the config file changed I still cannot see where I went wrong. Since fog told me the snapin ran, I suppose that %~p0 worked as path substitution. It also is working in another snapin pack I use. So I can’t see why my snapin pack solution did not work.

So much for documenting my results here.

Thanks again!!

I just saw, that it is a duplicate of https://forums.fogproject.org/topic/12484/office-deployment-toolkit-2016-snapin-problem - sorry.

Nonetheless, maybe there are solutions / better options now.

Hello,

I created a snapin pack to Install Microsoft 365 that fog registers as successful run while it is not working.

I already searched the forum and found similar attempts to install Microsoft 365, but none of the Topics are marked “solved”.

My snapin pack has the structure:

./install.cmd
./Setup/setup.exe
./Setup/MS365-config-64-bit.xml

Fog runs install.cmd which looks like:

net use x: \\truenas\MS365 /USER:Guest /PERSISTENT:NO
%~dp0Setup\setup.exe /configure %~dp0Setup\MS365-config-64-bit.xml
net use x: /DELETE

The relevant parts of the setup configuration .XML file are:

<Configuration ID="5c579236-99be-41f4-ba55-91c6e3c0e212">
  <Info Description="Test" />
  <Add OfficeClientEdition="64" Channel="Current" SourcePath="x:" AllowCdnFallback="TRUE">
    <Product ID="O365ProPlusRetail">
          <Language ID="de-de" />
          <Language ID="en-us" />
        </Product>
  </Add>
  <Updates Enabled="TRUE" UpdatePath="x:" />
  <RemoveMSI />
  <Display Level="None" AcceptEULA="TRUE" />
</Configuration>

Running install.cmd as local Administrator from a command line with elevated privileges in a machine belonging to an AD is working fine.

Running it via the analogue command to cmd.exe /c "[FOG_SNAPIN_PATH]\install.cmd, which is generated on the snapin pack page, with the full path via “RUN” on windows I get the same result (a popup window from setup.exe) as from a non-privileged command line. Therefore I think it should work when fog runs it as privileged SYSTEM user.

Running it via snapin on the same machine creates a “successful” run with exit code 0 and a runtime of 2 seconds.

The fog client log contains:

 07.03.2024 08:54:05 Client-Info Client Version: 0.13.0
 07.03.2024 08:54:05 Client-Info Client OS:      Windows
 07.03.2024 08:54:05 Client-Info Server Version: 1.5.10
 07.03.2024 08:54:05 Middleware::Response Success
 07.03.2024 08:54:05 SnapinClient Running snapin Install Microsoft 365
 07.03.2024 08:54:05 Middleware::Communication Download: https://192.168.0.43/fog/service/snapins.file.php?mac=44:37:E6:6F:32:8F&taskid=1376
 07.03.2024 08:54:06 SnapinClient C:\Program Files (x86)\FOG\tmp\MS365-x64-2.zip
 07.03.2024 08:54:06 SnapinClient Processing SnapinPack MS365-x64-2.zip
 07.03.2024 08:54:06 SnapinClient Extracting SnapinPack
 07.03.2024 08:54:06 Bus Emmiting message on channel: Notification
 07.03.2024 08:54:06 SnapinClient Starting snapin
 07.03.2024 08:54:06 SnapinClient Snapin finished
 07.03.2024 08:54:06 SnapinClient Return Code: 0
 07.03.2024 08:54:06 Bus Emmiting message on channel: Notification
 07.03.2024 08:54:06 Middleware::Communication URL: https://192.168.0.43/fog/service/snapins.checkin.php?taskid=1376&exitcode=0&mac=44:37:E6:6F:32:8F&newService&json

Any hint on how to enable a higher log level on the client or alternative attempts to either debug the problem or another way to install / update Microsoft 365 would be highly appreciated.

Thanks,

Paul

@hsikkema

Are you sure, that fog is the best solution for this?

Just for updating the software it is quite some overhead and a lot of writes on your hard disks.

I keep my Ubuntu PCs up to date with unattended upgrades. To just download the packages once I use apt-cacher-ng but you could also setup your own mirror of the Ubuntu repos with something like rsyncmirror.

If you start your clients via BIOS / UEFI alarm function or via wake on lan you can control the time when the updates are applied. Of course you could throw cron in the mix and don’t use unattended updates. This probably would be a way to work around user experience issues on older machines if you don’t want an update to start while user is in front of the machine. In this scenario you also would have to disable the desktop specific GUI - update mechanism to prevent it from nagging your users.

Hello SERR,

Did I understand correctly all what i need in settings is set multiple partition image - all disks?

Depending on your operating system and the hardware you use this is true. If all of the PC’s have the same hardware, it should work. Of course you’ll have to take care of the licensig of the operating system if you don’t use Linux.

If you don’t have the same hardware and you want to deploy Windows you should create a golden image and think about driver injection.

And can FOG deploy from image correct ssd - ssd and hdd - hdd (i have this issue from clonezilla sda was cloned to sda but disks can not correct plug in motherboard)

I capture the images inside a VM and deploy to ssd and hdd. I don’t think that there should be a problem. Also cloning an old hdd to a new ssd via dd or ddrescue never caused a problem for me.
If you want to copy it to a different computer with different hardware it could be possible that drivers were missing. But I never used clonezilla, so I’ve got no expierience there.

And so i interested of speed of deploying to PCs (i want to deploy for 5 pc simultaneously). All network is 1G

Fog supports multicast sessions suited for larger groups of computers. I deployed my image to about 10 PCs over 1 GB network without multicast and it was really fast enough for me, but I did not take the time. It definitely was faster than I thought it would be.

@george1421 said in Windows 10 UEFI golden image hangs on installation:

UEFI exit modes. There are only two. rEFInd and EXIT. All other modes are for BIOS computers.
So if you change the firmware to boot off the hard drive does it work correctly after imaging?

Thanks for the clarification. I was confused since all options are available in the BIOS and in the UEFI dropown.

I forgot to mention in my original post, that I also tried EXIT. The results were not conclusive to me. It seems I did not try it often enough on all devices.
I tried it again and now it seems to work on the Dell, but on the Acer after the first boot, going to the UEFI boot selection screen and booting Windows the boot order in the UEFI settings is reset to boot from the harddrive first. On KVM with EXIT I also get to the UEFI boot selection screen, but here (during system preparation) the default does not get reset to the Windows boot manager.

Changing the boot order and booting directly from the harddrive did work after imaging. Since I don’t plan to image that often the workaround to manually enter pxe boot is viable for me.

I have seen bad drivers do this, OR leaving the fog client service enabled before you sysprep the computer.

To prepare the golden image I added the necessary steps to a batch file to prevent forgetting one of them. It executes:

copy runonce.bat "%appdata%\Microsoft\Windows\Start Menu\Programs\Startup\"
del /s /q C:\customize\Win10
del /s /q C:\customize\Office_Deployment
cd c:\Windows\System32\Sysprep
net stop wmpnetworksvc
net stop fogservice
sc config FOGService start= disabled
sysprep.exe /generalize /oobe /shutdown /unattend:C:\customize\customize.xml

So the FOGService should be disabled and later reenabled via the setupcomplete - script after installing Windows. I did my original setup according to https://wiki.fogproject.org/wiki/index.php/FOG_Client .
Running sc config FOGService start= disabled in cmd seems to work also with Fog client 13 (I still have an older version in my BIOS golden image where everything works).
I’ll try running the commands one by one on my next try.

Concerning possible problematic drivers, I will create a new minimal viable golden Image without the virtio drivers (I used virtio-win-0.1.229.iso on my original UEFI image - just for reference) and report back.

Thanks for your feedback!

I recently went through this and used the script I posted in this thread to create the EFI entry for the windows boot.

Since the Windows installation is starting when booting to the harddrive I suppose the EFI entry exists.

The Image must be in GPT format, or at least I had no luck with MBR…

The drive was formatted during the Windows installation and I checked it now. It is GPT.

I never got to the Windows boot loader at all with CSM disabled until I used GPT and the script I posted at the link above. My machines would just hang at a black screen, and the drive was not seen in the EFI BIOS until I set the EFI entry as described using efibootmgr in that script. Though I have to say I am not sure I ever tried a GPT image without the script.

I had a similar problem before I recognized, that I had to use an UEFI machine to capture the image. But now I just get the two blue screens with "One moment please … " and the other one with “Why did my PC reboot”.

I made my image in VirtualBox set to EFI, though I had to turn off EFI to get Virtual Box to network boot and not fire up the golden image, ruining it due to it already being sysprepped, but that is a different story.

This works for me in KWM as expected. I am able to network boot either via boot menu or when set in the boot order.

Hey there and thanks for this great forum. It helped me a long way.

I managed to create a Win 10 golden image for legacy bios and to deploy it. Once I got it down it worked great.
Now I have to do it for UEFI since we got PCs without legacy / CSM as a boot option.

I’m using fog 1.5.10 (upgraded from 1.5.9)

I create the golden Win 10 22H2 Image from in a KVM VM on Ubuntu 22.04 with its firmware set to UEFI x86_64: /usr/share/OVMF/OVMF_CODE_4M.fd
Harddisk and network is set to virtio. So the virtio drivers are installed in the image. It is the same setup as for the legacy boot image.

After running sysprep I capture the Image.
My capturing settings are: Single Disk - Resizable; Everything; Partclone Uncompressed
I don’t think, that it matters, but Compression is set to 0.

When deploying I have two issues:

The first one, I could work around, is that I am not able to find the correct exit mode for the fog menu to allow booting from the first harddisk. I tried all of them:

When leaving it empty or using REFIND_EFI I get:
Could not boot: Permission denied (https://ipxe.org/0216ea8f) which hints at a incorrect certificate name.

GRUB, GRUB_FIRST_HDD, GRUB_FIRST_FOUND_WINDOWS: reentering fog menu

SANBOOT:
Boot from SAN device 0x80 failed: no such device https://ipxe.org/2c222087

I get this behaviour on different devices like the Acer TravelMate P614-51T-G2; Dell OptiPlex 3000 and a Lenovo ThinkCentre M81 from 2012 and even on the VMs when I use UEFI mode. The Lenovo works fine in auto or legacy mode but the other two machines miss this option.

Secure boot is disabled on all the machines.
I just swichted from ipxe.efi as bootfile to snponly.efi for uefi boot. Since my Problem is exiting and not booting up I think it makes no difference.

I think similar problems have already be reported.
For me, I could get around this whole issue by manually starting the network boot, but I wanted to address it nonetheless. Maybe the Error messages are useful and / or related to my core issue.

but the hard problem is:

When deploying the Win 10 Image it gets written on the disk, and on installation it hangs with “Einen Moment bitte …” (A moment please …) and sometimes shows the “Why did my PC reboot” screen. I’m sorry that I probably miss the english titles of the screens, I just did the german installation.

I used the same unattend.xml and the same software in the Image.
The Windows drivers get deployed via postdownloadscript as described in https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog

I thought I had to install one or two drivers directly to the Image for one of the legacy boot machines, but since the new computers are different, I would assume that they should not need this. Also I don’t remember what drivers they were. When comparing the installed drivers on the two pre - sysprep VMs with driverquery the only difference I could find was the version of the virtio - drivers.

This also happens when deploying to a VM with the same configuration as the one the image got captured.

I tried sysprepping and capturing again, but got the same result.

The only difference left other than the firmware to the legacy boot vm is, that I did not use the whole disk for Windows on the UEFI VM. I left some space for a future Linux dual boot setup.
I’ll try to create a new VM with just Windows on its hdd tomorrow.

Nonetheless I would really appreciate if anyone who had similar problems could point me in a direction.

Sorry for the wall of text, but it seems that I am not able to find the sweet spot between a thorough description of the problem(s) with possibly relevant information and a wall of text that nobody wants to read.

best regards,

Paul