I’m playing with it and got it nearly there by unt-ticking/re-ticking the AD join options in the individual host’s entry, then all my defaults populated nicely. Now have enough to go about tweaking with fog.log as you mention.
Other than Single Disk - Resizable option there is three other choices.
a) Multiple Partition Image - Single Disk(Not Resizable)
b)Multiple Partition Image - All Disks(Not Resizable)
c)Raw Image (Sector BY Sector,DD,Slow)
Which of these do I choose?
Btw, I have an additional question. Is it okay to capture and deploy image without doing sysprep? Or is it a must to do sysprep?
Sysprep is not needed in general. FOG doesn’t care if you sysprep or not. BUT Windows will need to be syspreped if you capture from one hardware model and deploy to another one being quite different. Good you bring up this point as I have not had that in mind. While I don’t think the hang on the blinking “_” can be caused by deploying to a different hardware as it’s very early in the boot process it’s very likely Windows will give you a blue screen later on in that case.
@Sebastian-Roth, não me atentei muito para a questão dos scripts. Mas já havia tentado executar um Snapin de script Shel e um .bat utilizando slmgr. Mas no windows o slmgr /ipk e /ato parecem ser inúteis. Vou ver novamente esses tópicos quando eu tiver mais tempo.
These issues are typically related to how the structure is on the disk and where the data is placed. Its not really a fog issue, but an issue how the reference image placed on the golden image disk. This is important especially if your golden image is constantly recycled as you apply round 2 (through N) updates and applications. The ideal method is to rebuild your golden image every time as you upgrade your golden image.
So how to fix…
Make sure your drive is the last partition on the disk. This may require you to move or delete the recovery partition. The recovery partition is a non-resizable and sometimes non-movable partition. I also question the value of a recovery partition if you have an imaging solution in place. It is much quicker to just reimage the computer than to try to recover a failed disk.
If you have done many updates to your golden image (especially over time) flush out all of your temp files and defragment the hard drive. This will (should) push all of the files towards the beginning of the disk. The idea/goal here would be to move all of the disk data below the size of the disk you will be deploying to. That makes FOG’s disk compression work a bit easier.
If you are developing a golden image create that golden image on the smallest disk possible. Its is easier to expand the disk than it is to shrink it. So if you developed your golden image on a 120GB SSD, that image would deploy cleanly to 120GB disks and larger, for example.
@Derek-Newbold FYI I have seen ton of people running FOG in AWS with totally public IP and that works outside of any firewall issues, of course those instances involve people who have access to the local sites DHCP so they can update the tftp option in their scopes with the public IP
In my case it’s a private IP but I do have access to the networking side of things so sites throughout the organization can boot fine from HQ FOG server.
It turns out that this was a problem with the Trusted Platform Module. Apparently it didn’t like the new O/S being installed on hardware it had already “signed”. Not being too schooled in how TPM works, I’m making an assumption here, but clearing the TPM after deployment fixed my bootup problem. This can be done in the BIOS, or by letting the system boot from the Hard Drive at the Fog Menu, then running tpm.msc and clearing it there.
@Base2Nathan I’m not asking to be rude but there’s hardly any information to work from.
All fog does from imaging is capture what you tell it to, and deploy where/when you tell it. It’s block level, so there’s nothing fog would be doing in regards to the programs you have installed or removed.
@Lee-Rowlett That is a sound route, I’ll keep it in mind while I dig into it.
Yeah, I was hoping it was some other reason than permissions, but somehow over the last week permissions changed on the server, so it is probably how I’ve got it setup.
The main system is installed on a 512 GB M.2 Nvme, and the images are stored on a 2TB HDD that I have mounted to the images folder. The permissions didn’t have a date last changed, so I’m guessing something happened with that mount at some point, maybe a power outage or brownout and maybe it reset the mount long enough to fubar the permissions?
@Fredorum We need more infos to be able to help. What software do you install? Have you tried installing this software manually (as well using the exact same parameters)? Do you get the desktop icon if doing it manually?
The fog-client runs as SYSTEM service account. This might cause the installer to act different to what you might expect. It might be easier to just create the desktop icon within a batch script that you run as snapin.