Posts made by Joe Schmitt

@emc sorry for the delay, feel free to bump the thread or send me a PM if it seems I’ve lost track of it. Would I be able to remote into one of the problematic machines? Send me a PM if this is an option and we can work out a time that works for both of us.

@jeffscott the quickest way to see what’s going on is to do the following steps on a problematic machine:

• Open an administrative CMD, and run net stop fogservice
• Navigate to your FOG server’s web portal, select the host you are working on and perform these steps:
  • Press Reset Encryption Data if its an option
• Download our Debugger.exe and run it
• The Debugger will open a console that has a fog: prompt, please enter these commands, pressing enter after each one (replace {server-ip} with your actual FOG server IP):
  • middleware configuration server http://{server-ip}/fog
  • middleware authentication handshake
  • dump cycle save

---

The debugger should point you to a FOGCycle.txt file. This contains all the information the server tells the client, completely decrypted. Can you make sure the hostnamechanger section has the correct active directory login/OU information? You can then hopefully debug the problem better and identify what credential the client is receiving.

To clean up:

• Close the debugger
• click Reset Encryption Data again on the host in the gui
• start back up the fog service if you want

---

@Moderators feel free to copy & paste these steps for people with similair issues in the future. The steps shouldn’t change in the foreseeable future.

@Szeraax the client itself is actually already 64 bit compatible. It gets installed as 32 bit because the msi targets 32 bit. I suppose going forward I could either make 2 different installers (one for each architecture) or build a single installer that can target either.

@Szeraax is correct. We do provide Snapin templates for both Powershell and Powershell 64 bit for this reason. Eventually when we allow the client to install as 64 bit on machines, then this problem won’t exist.

@irfan4701 - @sudburr is correct. Windows server 2012 is based on Windows 8 / is called Windows Server 8. Likewise, Windows server 2016 is based on Windows 10.

@Lemeunier I don’t have time for a detailed response at the moment, but I would recommend you look at: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server

Edit: I just realized I already posted this link earlier, sorry for the duplicate

I remoted in and helped identify the problematic adapter.

I’m currently working on a way for the client to automatically filter out virtual interfaces to help prevent these kinds of issues in the future.

@davido38 this is a Windows error code. From what I gathered looking online, it means:

Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

Do you have some kind of persistent file mount to your server that is using different credentials than the one your FOG server uses? Or was a snapin run that mounted a network share, and it wasn’t properly unmounted?

@raviolipizza I took a look at your client logs, and it appears to be a bug with the server ( @Tom-Elliott ). The other option is that you do actually have an imaging task pending, but the computer isn’t set to boot to PXE.

This is my theory based on the log: Snapins are being registered as a task reboot (they shouldn’t be), here’s why:

• You stated that the reboot loop once you cancel the Snapin
• In the log, the client reboots 8 times because of a pending imaging task:

------------------------------------------------------------------------------
----------------------------------TaskReboot----------------------------------
------------------------------------------------------------------------------
 13.04.2018 07:48 Client-Info Client Version: 0.11.15
 13.04.2018 07:48 Client-Info Client OS:      Windows
 13.04.2018 07:48 Client-Info Server Version: 1.5.0
 13.04.2018 07:48 Middleware::Response Success
 13.04.2018 07:48 TaskReboot Restarting computer for task
 13.04.2018 07:48 Power Creating shutdown command in 60 seconds
 13.04.2018 07:48 Bus Emmiting message on channel: Power
------------------------------------------------------------------------------

• Therefore the server is telling the client there is a pending task that requires booting into FOS.
• On reboot, iPXE doesn’t register that there’s a task to boot into FOS
• So my best guess is that when talking to the client, the server must be including snapin tasks as a “You need to restart into FOS” task

@chaonatic okay, so that points to the virtual network adapter theory. Does your VM have any software-defined adapters that would be copied during imaging? Such as for a VPN, VirtualBox, or some other tunnel?

@jpaul Can you start back up the service (or restart the computer) and try clearing the OU field in the FOG interface? {yourdomain}.local as the OU could be causing some issues.

@jpaul when you ran middleware authentication handshake did it give you an error in the Debugger?

@jpaul ok good, just wanted to make sure before we look at other things. So the next thing I want to make sure of is that the client is getting the right information from the server.

Can you try the following steps on this problematic machine?

• Open an administrative CMD, and run net stop fogservice
• Navigate to your FOG server’s web portal, select the host you are working on and perform these steps:
  • Press Reset Encryption Data if its an option
• Download our Debugger.exe and run it
• The Debugger will open a console that has a fog: prompt, please enter these commands, pressing enter after each one:
  • middleware configuration server http://10.1.13.50/fog
  • middleware authentication handshake
  • dump cycle save

---

The debugger should point you to a FOGCycle.txt file. This contains all the information the server tells the client, completely decrypted. Can you make sure the hostnamechanger section has the correct active directory login/OU information?

To clean up:

• Close the debugger
• click Reset Encryption Data again on the host in the gui
• start back up the fog service if you want

@jpaul was this machine imaged? If so, was the image itself joined to active directory?

@chaonatic the simplest way to find the duplicate mac is to open a sql prompt on your FOG server;

Run: mysql -u root -p, and enter your sql root password.

Then run the following commands (replacing the list of macs with the ones the client is using):

use fog;
SELECT * FROM hostMAC WHERE hmMAC IN ('00:01:00:00:00:66', '00:01:00:00:00:67');
exit;

Ideally each mac address should only appear once in the hmMAC result column. If there is one that appears multiple times, that is the culprit.

In general though, these kinds of errors are usually caused by virtual network adapters in your image.

@jpaul said in auto join. AD:

sed the first line in fog settings / active directory settings/ and did not encrypt the password … also try to encrypt the password even tried the lagacy option using the encrypted password. None of these work. Is there another place to input this info besides fog settings/ active directory settings. Thanks

The first place to look for debugging client issues is C:\fog.log on a computer with the issue. In the HostnameChanger section it should point to a reason why its not being added to active directory (feel free to attach your log file if you are having issues finding out why).

@amerhbb said in Active Directory Join Failing:

out the password and the login which be added in FOG server in the menu “Active Directory default”, I used “My_AD_Admin” for user and i used “My-AD-Admin-password” for password.

The field marked LEGACY is only for the old client (XP era). You just need the non-legacy field set.

@amerhbb said in Active Directory Join Failing:

this image is already join domaine but when i deploy this image the cliens arn’t in AD ???

Images should not be joined to Active Directory as it can cause many issues. An image should be unjoined, and after deployment, the computer should then be joined (using the client or a custom script).

In general using the client is the simplest way, though there are other ways of doing it. Your actual image cannot be joined to Active Directory. You can instead use the FOG Client, or if your image is sysprepped you can use unattend.xml or some custom script.

@lemeunier see this article for how to keep control of your clients:

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