Windows 10 Domain Issue

[Towndrunk]

I guess I wouldn’t worry about looking at this since it is solved.

I imaged a computer that was activated and on the domain. After applying that imaged to another computer it says that is on the domain when I log in locally, however there is no trust relationship. Once I remove the PC from the domain, and reboot, it is added back to the domain and I’m able to log into the domain. It only does this if I remove it, not if I just reboot.

Once I log into the domain, I see that Windows is no longer activated, and it will not active with the same VLK that is in the computer I made the image from. I’m not sure what is going on, but I loaded an image from the Default Lenovo Windows 7 that we updated to Windows 10, and it activated with no issues. Not sure why it is a problem on the VLK. We are just going to use the other image and see what happens.

Is this normal, or just an issue with Windows 10? I used FOG with Windows 7 for years with no issues ever. Now it seems as though I can’t get anything to work together. Thanks for taking a look at this.

[Towndrunk]

@Tom-Elliott I made a new Image, and checked that it was not joined to the domain. I have the default credentials in the Fog Settings and made sure that the Host I was deploying the new image to was set to add to the domain. I also made sure that I ran all the updates on the FOG server and put the new client on the new Image

Once I deploy, the image works fine but it does not add to the domain. I went to the log and this is what I get. I know it can talk to the domain because if I use the same credentials I put into FOG it adds with no issues.

7/25/2016 10:01 AM FOG::HostnameChanger Attempting to join domain if not already a member…
7/25/2016 10:01 AM FOG::HostnameChanger Domain Error! (‘Unknown Error’ Code: 1326)

7/25/2016 10:02 AM FOG::UserTracker Event: LOGIN for TEST-TEST-TEST\User
7/25/2016 10:02 AM FOG::UserTracker Unhandled Response from server:
7/25/2016 10:02 AM FOG::PrinterManager Failed to connect to fog server!
7/25/2016 10:02 AM FOG::PrinterManager This is typically caused by a network error!
7/25/2016 10:02 AM FOG::PrinterManager Sleeping for 1 minute.

0_1469456167661_FOG LOG.txt

[Joe Schmitt]

@Towndrunk that log indicated you are still using the legacy client.

[Tom Elliott]

It also seems to indicate a FOG version that had this broken.

What version of FOG are you running @Towndrunk?

[Towndrunk]

I updated it on Friday before I made my new base image. After making the image I went to Service Configuration and downloaded/installed the FOG Client from there. I was assuming that was the most up to date version.

I just checked and I appear to be out of date now, but I’m running the following.

Running Version 1.3.0-RC-1
SVN Revision: 5936

[Tom Elliott]

@Towndrunk But if you updated, why is your client still using the legacy client?

While it is true the “new client” does autoupdate, that’s only if the new client is installed on the image. If you have the old fog client installed, you are not working with the new client.

[Tom Elliott]

Further help:

https://wiki.fogproject.org/wiki/index.php?title=FOG_Client

[Towndrunk]

I just ran the update, and then downloaded the client again to install. When I tried to install it, I received a message telling me to “Please uninstall the legacy client and re-run this installer”. I went to Programs and Features and uninstalled the FOG Service, and rebooted. When I go back in and try to run the install I get the same message.

Running Version 1.3.0-RC-2
SVN Revision: 5937

[Tom Elliott]

https://forums.fogproject.org/topic/7758/client-install-issues-legacy-uninstall/12#

[Towndrunk]

@Tom-Elliott Thanks, I found that while I was searching after I posted. I don’t have any Keys starting with 91C5D423 in that location. I was thinking the same thing, searing the registry to remove anything related to FOG Service, but I wanted to see if I was missing something first.

Is it possible that it is another entry in that same location?

[Joe Schmitt]

@Towndrunk that is the exact registry key the new client uses to detect a legacy installation. If the installer reports that the legacy client is still on your system than that registry key must exist.(make sure to include the curly brace in your search). If it still doesn’t show then search the whole registry for that exact key, and if you could report your findings.

It may be in a different root folder, but the path will always contain SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and be in the local machine root section.

[Towndrunk]

@Joe-Schmitt thanks for the response. I did a search for it and found it in another directory. The directory below is where I found it, not sure how you make it red like yours. I removed it and was able to install the new client. I’m going to do another capture and see if I get a different response.

HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall

[Towndrunk]

Thanks so much for the help. I would not have figured that out without your help. Once I remove the old client, updated to the new, and ran a new capture. . . I’m able to deploy with no issues now. It is adding to the domain as we had hoped now.

[Wayne Workman]

@Towndrunk said in Windows 10 Domain Issue:

I imaged a computer that was activated and on the domain. After applying that imaged to another computer it says that is on the domain when I log in locally, however there is no trust relationship.

If your image is already joined to the domain, you will have nothing but problems, and major ones at that. There is no imaging solution made by anyone that would suggest taking an image from a domain-bound computer. They all suggest exactly the opposite, take an image of an un-bound system.