@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.
Posts made by Joe Schmitt
-
RE: SnapinPack SnapinClient ERROR: 1 is not a supported code page. Parameter name: codepage
-
RE: Active Directory Join Failing
@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
- Press
- 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 thehostnamechanger
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.
- Open an administrative CMD, and run
-
RE: Powershell snapin and registry
@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. -
RE: Powershell snapin and registry
@Szeraax is correct. We do provide Snapin templates for both
Powershell
andPowershell 64 bit
for this reason. Eventually when we allow the client to install as 64 bit on machines, then this problem won’t exist. -
RE: Cloning windows server 2012r2
@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.
-
RE: Client does not communicate with Fog server
@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
-
RE: Fog Client 0.11.15 ERROR: Object reference not set to an instance of an object.
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.
-
RE: Active directory join error 1219
@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?
-
RE: Restart loop after deploying snapin
@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
-
RE: Fog Client 0.11.15 ERROR: Object reference not set to an instance of an object.
@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?
-
RE: auto join. AD
@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. -
RE: auto join. AD
@jpaul when you ran
middleware authentication handshake
did it give you an error in the Debugger? -
RE: auto join. AD
@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
- Press
- 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 thehostnamechanger
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
- Open an administrative CMD, and run
-
RE: auto join. AD
@jpaul was this machine imaged? If so, was the image itself joined to active directory?
-
RE: Fog Client 0.11.15 ERROR: Object reference not set to an instance of an object.
@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.
-
RE: auto join. AD
@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 theHostnameChanger
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). -
RE: Active Directory Join Failing
@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. -
RE: Active Directory Join Failing
@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).
-
RE: Active Directory Join Failing
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. -
RE: Client does not communicate with Fog server
@lemeunier see this article for how to keep control of your clients: