My guess is the database upgrade from 1.2.0 didn’t go as smoothly as I had thought. I probably should have checked some of the tables just to see. Setting the pConfig to “Local” in the database filled in “TCP/IP” in the Printer Type column when clicking on List all printers.

I just fixed my “second” printer issue. There was an & sign in the path to the inf file and the fog gui was showing & for some reason. I removed that from the gui and removed the & from the server path and the printer installed correctly. Strange how there was no error in the fog log but I’m guessing that’s not something you can query?

@Sebastian-Roth I was actually able to compile that dll myself. Looks like it’s throwing on the GetComputerDomain() line in both cases. Trying to join the domain and after I manually join the domain. So I don’t think that’s the problem. It’s failing on the NetJoinDomain() function. I think I need to print out the variables to see if they’re the same for a good image and a bad one.

@sebastian-roth I took some time to do a little debugging into my issue and it seems that the following line in fog-client\Modules\HostnameChanger\HostnameChanger.cs isn’t working correctly in Windows 10 (21H2).

if (Environment.MachineName.Equals(msg.Hostname.ToLower(), StringComparison.OrdinalIgnoreCase))

When I print out Environment.MachineName it shows the updated name even though the actual machine name has not been changed. I can check it in the Windows settings to make sure. It looks like Environment.MachineName is being updated before the name is actually changed. I think this explains why if I manually change the machine name it then joins the domain properly. Any thoughts?

Thanks

@sebastian-roth Sounds good. One more point of interest. If I remove that if completely the computer gets renamed and joins the domain correctly. I guess leaving it that way will make the client try to change the name and attempt to join the domain over and over again.

Thanks

@sebastian-roth Not sure if I’m reading the code correctly but doesn’t the RenameComputer function in HostnameChanger.cs happen before the RenameComputer function in the WindowsHostName.cs file? If so I think the Environment.MachineName.Equals call is already incorrect meaning it thinks the computer has already been renamed. I thought the RenameComputer function call to the WindowsHostName.cs file was in the try right after the “Renaming host to” log message which in my case I never get to. Hope this makes sense.

Thanks

@sebastian-roth Thanks for the reply. Yes, I think adding an appropriate message would be nice. I’ll keep the image that causes the 2725 error around just in case but at this point I’m not quite sure how or what else to debug. If you have any thoughts in the future and would like me to test just let me know.

Thanks

Just replying to this with some updated information after my latest upgrade to Ubuntu 20.04 so I don’t forget on the next upgrade. I couldn’t get the fog installer to work without the -X option but figured out what the issue was. I needed to edit the /etc/pam.d/common-password file and change the following line to 10000 instead of 1000.

password        [success=3 default=ignore]      pam_krb5.so minimum_uid=1000

This was because the fogproject user was more than 1000, so changing it to 10000 let the installer work without needing the -X option and the password was updated properly. I then switched it back to 1000 so kerberos would work with my AD accounts.

@sebastian-roth Thanks for the reply. Yes, I think adding an appropriate message would be nice. I’ll keep the image that causes the 2725 error around just in case but at this point I’m not quite sure how or what else to debug. If you have any thoughts in the future and would like me to test just let me know.

Thanks

@sebastian-roth I think I may have tracked down my issue and I think it may be my fault. In my testing I was able to manually change the computer name and then the client would join the domain. I then disconnected from the domain and changed the name back to the original name and rebooted. The client then renamed the computer and joined the domain by itself. I decided to take an image of the machine at this point by first disabling the change hostname and join domain options in the fog web gui for that machine and then rename the computer back again and disconnect from the domain. I then loaded this new image on the same machine after re-enabling the change hostname and join domain in the fog web gui, and loaded it on a second machine and they both renamed and joined properly. My guess is I had never joined the domain with the first image I created. It was as clean an image as I could get. If this makes sense I think this was my issue.

Thanks

@sebastian-roth Not sure if I’m reading the code correctly but doesn’t the RenameComputer function in HostnameChanger.cs happen before the RenameComputer function in the WindowsHostName.cs file? If so I think the Environment.MachineName.Equals call is already incorrect meaning it thinks the computer has already been renamed. I thought the RenameComputer function call to the WindowsHostName.cs file was in the try right after the “Renaming host to” log message which in my case I never get to. Hope this makes sense.

Thanks

@sebastian-roth Sounds good. One more point of interest. If I remove that if completely the computer gets renamed and joins the domain correctly. I guess leaving it that way will make the client try to change the name and attempt to join the domain over and over again.

Thanks

@sebastian-roth I took some time to do a little debugging into my issue and it seems that the following line in fog-client\Modules\HostnameChanger\HostnameChanger.cs isn’t working correctly in Windows 10 (21H2).

if (Environment.MachineName.Equals(msg.Hostname.ToLower(), StringComparison.OrdinalIgnoreCase))

When I print out Environment.MachineName it shows the updated name even though the actual machine name has not been changed. I can check it in the Windows settings to make sure. It looks like Environment.MachineName is being updated before the name is actually changed. I think this explains why if I manually change the machine name it then joins the domain properly. Any thoughts?

Thanks

Just trying to get a Windows 10 machine to connect to my AD domain. I’m running FOG 1.5.9 on Ubuntu 18.04 and I’ve finally been able to upgrade my domain from NT4 to AD. I’m running the 0.12.0 client but get the following error message. If I manually change the computer name to what it should be, fog then connected to the domain and everything else seems fine. I re-imaged back to Windows 7 just to see and both the name change and joining the domain work properly. So it only seems to be the name change on Windows 10 that’s an issue. Any ideas what the 2725 error is?

------------------------------------------------------------------------------
--------------------------------HostnameChanger-------------------------------
------------------------------------------------------------------------------
 2022-01-15 11:16:50 AM Client-Info Client Version: 0.12.0
 2022-01-15 11:16:50 AM Client-Info Client OS:      Windows
 2022-01-15 11:16:50 AM Client-Info Server Version: 1.5.9
 2022-01-15 11:16:50 AM Middleware::Response Success
 2022-01-15 11:16:50 AM HostnameChanger Checking Hostname
 2022-01-15 11:16:50 AM HostnameChanger Hostname is correct
 2022-01-15 11:16:50 AM HostnameChanger Attempting to join domain
 2022-01-15 11:17:20 AM HostnameChanger Unknown Return Code:  2725

Thanks

@Sebastian-Roth Just tested this out and it works. I just modified the inventory_report.report.php file to match your change.

Thanks

@Sebastian-Roth Now that I’ve upgraded my system to 1.5.9 I tried out the Inventory Report again. If I choose a model name from the list but not a group name I seem to get all machines instead of just the specific model. The list seems to be the same as when I don’t choose any model name or group. Should I be able to choose a model without a group?

Thanks

@Sebastian-Roth Just upgraded my production machine to 1.5.9 without using the -X option and it worked. I think the difference is on my test system I’ve migrated from a Samba NT4 domain to a Samba Active Directory domain. If you want any extra info on my test system to fix anything with the installer just let me know but I think I’m good to go.

Thanks