WSUS with Fog 1.3

[Matthieu Jacquart]

Server

• FOG Version: 1.3 RC11
• OS: Debian 8.5

Client

• Service Version: 0.11.5
• OS: Windows 10

Description

Hi,

I haven’t this problem with Fog 1.2 and even with previous svn 1.3 before this summer, but now when I’m deploying Win10 syspreped image, in my WSUS console clients appear with default syspreped name (for example test-dfdsf212sd, before hostaname changer), and they roll back to default group. So each time I fog client, I had to put it in the right wsus group, and sometimes it takes few days to wsus for having right name and scan computer for updates.

I don’t have this problem before this summer, but I migrate all my computers from Win7 to Win10, so I don’t know what is the cause…
I made a small test : non-sysprep image (just remove client for AD before uploading image) don’t have this problem (which seems logic), name is ok, group is ok and check for update is ok instantly.

Thanks
Matthieu

[Tom Elliott]

If I had to guess, WSUS is checking in to the console before the FOG Client has had a chance to change the name. You might be able to work around this by disabling the wuauserv service, then, similarly to the re-enabling of the client (after the client has been re-enabled and started), re-enable the service.

[Matthieu Jacquart]

@Tom-Elliott That’s a nice idea, I’ll test it tomorrow !
Is there a way to delay start of the wuauserv service in setupcomplete.cmd ? To be sure that fog change hostname before wuauserv service runs ?

sc config FOGService start= auto
shutdown -t 0 -r

[Tom Elliott]

@Matthieu-Jacquart I think you’d just do what you do with FOGService.

Disable wuauserv, sysprep and upload. On deploy, in the setupcomplete.cmd script, just run: sc config wuauserv start= auto, you wouldn’t even need to start it, because the reboot will do it for you. The client is fast, but in sysprep phase, the client isn’t running until it hits setupcomplete.cmd.

[Matthieu Jacquart]

@Tom-Elliott Just tested, failed, same problem… Return to default group with syspreped name

[Joe Schmitt]

@Matthieu-Jacquart you could try enabling wsus via a snap in. That way the client finishes all of its hostname work before it starts wsus.

[george1421]

@Matthieu-Jacquart Please let me understand this issue here as it relates to what we do.

We build our golden image with mdt and have all current win updates applied. This creates an entry in WSUS. The name of the system in WSUS is the default name of our golden image. We have this computer in our build up group in WSUS. Then we sysprep the image, and capture with FOG. When we deploy the image OOBE runs since the image was sysprep’d OOBE creates a new SID for the computer and wsus registers this device with the wsus server with its new name (we have the unattend.xml give the system its proper name as well as connect it to AD and not use FOG for this function). Since this is a “new” system with a new SID WSUS will add this computer to the default group in WSUS (because its a new computer). This is expected.

There are gpo settings where you can target a computer to a specific WSUS group, but we haven’t found this to work as we expected between the target computer and WSUS. The idea is great, in that the target OU would determine what WSUS the computer belongs to. We use that same GPO to assign the computer to the proper (local) WSUS server. That part works.

But Joe’s suggestion of letting a snapin enable wsus is brilliant because snapins run after all of the system maintenance stuff is done

[Matthieu Jacquart]

@Joe-Schmitt Ok that’s great !
Tested on 40 pc, it resolves my problem, thanks