Topics created by RobTitian16

@RobTitian16

I realize this is a few month’s old. But you might want to check out and or contribute to the fog module I have in git and published in the powershellgallery, there’s a forum post with more info here https://forums.fogproject.org/post/120746
Also did you have a chance to try the code I posted back in september and see if that worked? Because it works for me.
And looking again at your code I would ask what the value of $useAD is, is it 1 it should be 1. And I would also try piping the object into convertto-json, I’ve had better luck with that, I think it parses it different i.e. $CreateHostJson = $HostJson | ConvertTo-Json I would also encapsulate everything in quotes on the splat.
The only other thing that might be an issue is the ADPass. When you get the password via the api it is returned in plain text (because you already authenticated with api keys, so it’s not like just anyone can grab it). When you input the password in the gui you put it in plaintext and it encrypts when you hit save, I don’t think the same thing happens if you set it through the api. My solution has been to always enable the default AD settings when adding a host via the gui or the pxe menu. But it sounds like you’re adding the host through the api. The “useAD”=“1” in the json should be causing the checkbox for the ‘join domain after deploy’ to be checked. Sadly when you check it from the api it doesn’t pull the default domain settings. You might try creating the host without the AD settings and then sending just the AD settings in an update/put command. If you copy paste the already encrypted password from a working host in the gui, that might do the trick as it seems to pass whatever you put in that field to be in plaintext.

So point is, try adding the domain stuff with an update api command after creating. And use the code I have in the example to help if needed.

@george1421 Actually, I’ve just figured it out for the most part. However, is there a way to set it to use the default values already set in FOG?
I’ve updated the JSON to have:
“useAD” = “Y”
This ticks the ‘Join Domain after deploy’ box. I don’t particularly fancy having to tap in the details for the system to join the domain when they’re already configured within FOG itself, though.

This can be marked as solved. I updated to 1.5.4 and everything is confirmed to be working once more. Thanks!

@tom-elliott Yes indeed, thanks very much!

@RobTitian16 Maybe do some datebase cleanup: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_MySQL#Database_Maintenance_Commands

I’ll mark this solved as the AD joining issue is actually solved. Please open a new thread if you still have the group assignment issue after the DB maintenance.

@jdd49 The image seems to have worked now after rebooting the Hypervisor this morning, though I’m now getting the following error message when trying to boot the VM:

0_1511280177376_1.PNG

I’ve recreated the VHD on a different Hypervisor and still run into the same issue. Annoyingly (but also thankfully), the actual physical machine I’m trying to virtaulise runs perfectly fine and doesn’t have this issue.

It turns out this is working fine - we just didn’t have the correct folder on our FOG server for the model of laptop (which the script relies on). We’ve made some adjustments to the script and can confirm this now works.
Thanks very much for the help!

@george1421 Thanks, George.
This turned out to be an issue with the dnsmasq update. We have now updated to the latest version (following a full removal of dnsmasq), and had to edit the /etc/dnsmasq.conf file to include the DHCP range again.

@george1421 It all uploaded perfectly fine the other day - thanks 🙂

@george1421 said in Replication Timing?:

First the generic recommendation. Please update FOG you are several versions behind and on an RC release that has a known bug with image resizing.

More than a generic one, this is a very strongly recommended and needed. We could end up wasting days on an issue in an RC that’s already fixed in the next stable release. Imagine asking Microsoft to help you fix something on a Windows 7 Beta copy.

@Tom-Elliott @george1421
Ah, so simple! Thanks very much gents!

It appears it’s an issue with the Unattend.xml file. I’ve tried one that has worked in the past and that’s absolutely fine.

Thanks for the help, gents!

@RobTitian16

Q1 Batch file: This is an independent batch file from MDT. We do a few clean up actions just before sysprep and power off. We do this via a batch file and at the end of the batch file it runs the sysprep command with a consistent syntax. That way we get the same exact action every time we build a master image and then sysprep it. It could be done manually by copy and paste, but its much easier to run the batch file. We do have the sysprepit.cmd file as well as some branding stuff installed as a MDT package. That is how it gets copied over to the reference image as a MDT package.

Q2 CAB file: Understand there are 2 different cab files in play here. We install the winpe cab file in the reference image since that contains the core drivers we need post deployment. The driver path /images/drivers/{hardware_type}/{os_type}/{arch}/{driver files} is the extract of the model specific cab file. If you give me a specific dell model I can point you to the proper cab file.

@RobTitian16 Thank you for your reply.

Did you build your Windows 10 image from scratch or are you using a modified version of the pre-installed os?

You could try wiping the drive of all partitions, adding a blank one and imaging again. We have had trouble with partitions on the disk that were put there as a factory recovery point. (I know Dell, HP, etc are known for having a recovery partition).

Ryan’s link worked! This can be marked as solved 🙂 Thanks gents!

@x23piracy While this isn’t FOG related, imaging rights are important to follow. If you want to survive an audit you should understand what you are allowed to do and can’t do.

Chris (from Microsoft) has posted 2 clear documents on what you can do with system imaging (from a MS perspective). This question comes up on Spiceworks almost daily.

https://community.spiceworks.com/how_to/124056-reimaging-rights-for-windows-10-licensing-how-to

https://community.spiceworks.com/how_to/69219-reimaging-rights-how-they-apply-to-your-licensing

Take these documents as a clear explanation of the MS EULA.

It is true if you have a single VLK key, you can deploy any number of systems as long as the OEM key is licensed for the same OS as the VLK key. For example if you have a single VLK key for Windows 10 Pro. You may reimage any number of computers that came from the manufacturer with Windows 10 Pro already installed. You may not use the VLK key for Win 10 Pro to deploy Win 10 Pro to a computer that had Win 8.1 previously installed. That is a different license (version upgrade).

@Tom-Elliott The register and image setup is confirmed to be working in the latest release 🙂 Thanks!

@Tom-Elliott Updated correctly now - not sure why it wasn’t working the other day. Thanks for the help once again!

@george1421 Still no dice with getting this to run with the legacy boot option.
I’ve cloned my FOG server for UEFI testing but the laptops don’t boot using IPV4 - they just hang. or say that the file is not found (going by the previous posts).

EDIT:
It seems to be working on a Dell E7270. I’ll test after the holidays with the other Dell laptop 🙂
Thanks for the help, George and everyone else! Much appreciated as always!

@Wayne-Workman I can confirm this is now working - I just had to re-image the system and sysprep it again. It’s now uploading fine.
Thanks for the help and suggestions 🙂