HostnameChanger question
-
@chunter2 Yes, you need to click the “Reset Encryption Data” button in this host’s settings on the web UI!
-
@Sebastian-Roth Thanks for that info. Took me a while to realize where the button was. Not like it’s not big enough.
Here’s what I’ve found so far. On a good image or bad image whether I’m joined to the domain or not IsJoindToDomain() always throws on the
using (var domain = Domain.GetComputerDomain())
line. Not sure what the purpose of that is but I’m running an NT4 domain, not an AD domain so it could be for that. Because this function fails the client is always calling NetJoinDomain() on every loop.On a good image that’s disconnected from the domain the first call to DomainWrapper() always fails. I think it’s because my ADOU is always empty. Again something with an NT4 domain? The return value is 50 so then DomainWrapper() is called again with false set. And then it connects.
On a bad image that’s disconnected from the domain the first call to DomainWrapper() fails with a 1219 and then doesn’t try again. I tried adding 1219 to the switch to call again with false set but it fails with a 1219 as well. Not sure what to try next.
Thanks
-
@chunter2 said in HostnameChanger question:
On a good image or bad image whether I’m joined to the domain or not IsJoindToDomain() always throws on the using (var domain = Domain.GetComputerDomain()) line. Not sure what the purpose of that is but I’m running an NT4 domain, not an AD domain so it could be for that. Because this function fails the client is always calling NetJoinDomain() on every loop.
As mentioned before this is known and documented in more details in a github issue.
On a good image that’s disconnected from the domain the first call to DomainWrapper() always fails. I think it’s because my ADOU is always empty. Again something with an NT4 domain? The return value is 50 so then DomainWrapper() is called again with false set. And then it connects.
On a bad image that’s disconnected from the domain the first call to DomainWrapper() fails with a 1219 and then doesn’t try again. I tried adding 1219 to the switch to call again with false set but it fails with a 1219 as well. Not sure what to try next.
Ok so the bad image/client seems to persistently return with the 1219 error. But on the other hand you seem to be able to manually join the domain.
Let’s see if we can manually get this right with the fog-client. Start the problem host, open two command shells, one as normal user and one as Administrator:
Admin cmd:
net stop FOGService
User cmd:
net session net use net use * /d /y
Admin cmd:
net session net use net use * /d /y net stop lanmanworkstation net start lanmanworkstation net start netlogon net start sessionenv net start FOGService
Take a picture of what you get from the commands
net session
andnet use
in both cmd shells. Now watch the fog-client log and see if it still returns error 1219. -
@chunter2 And if that doesn’t help we can still go ahead and capture network packets on your Samba server or enable debug logging to see if the client opens another SMB connection.
-
@Sebastian-Roth All the net use and net session commands return “There are no entries in the list”. So there’s nothing to delete. I’m connected using RDP on all these machines (good and bad images) so I can’t stop the lanmanworkstation service. If I run net use or net session on a good image I get the same message. I think network packets and debug logging on the samba server makes sense to try next. I’ll have to look into that.
-
@chunter2 Ok, then let’s go ahead. Install
tcpdump
on your Samba server and get the bad unjoined imaged host ready. Don’t start it yet. Now run this command on your server and let it sit there:tcpdump -i eth0 -w /tmp/netdump.pcap host x.x.x.x
Put in the correct host IP and your server network Interface if it’s not eth0.
Boot the host and wait for 10 minutes. Then stop tcpdump by pressing Ctrl+c. Copy the generated file over to another system, upload and post a Link here.
-
The PCAP revealed that there were some left overs from an old software that would open an application on a public network share on boot up of that system. Removing that stuff fixed the issue and fog-client domain join works perfectly fine now again.