Join Domain error 1219
-
I know it’s a bit late, but on the system you’re having this problem with, what does your c:\fog.log file state in regards to the hostname changer. Or is that what you’re referencing in this message?
-
Thank you für your reply.
Yes, that’s what the log file state’s. The change of the hostname work’s fine, but joining the domain fails (DELL optiplex 790). With the same image on another machine (optiplex 780) the domain join work’s fine.
Could it be, that the Domain joining process start’s too soon when other Network processes (GPOs, …) are still working?
-
This post is deleted! -
We have recently been experiencing the same thing here with Windows 7 on several different systems. Was working since last Summer but now:
C:\fog.txt is showing HostnameChanger Domain Error! (‘unknown error’ Code:1219)
on this machine after imaging when trying to join domain any ideas
Name change works fine on all systems though.
-
I believe this is the error description you are seeing:
[B]ERROR_SESSION_CREDENTIAL_CONFLICT[/B]
1219 (0x4C3)
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.
[LEFT] [/LEFT]
Not saying it’s very helpful but maybe it can get you pointed in the right direction. I could also be off on a tangent but figured it would be worth mentioning.
[LEFT] [/LEFT] -
I have a feeling what’s stated above is probably correct. The indicator, to me, seems to be that it works in some cases, and fails in others. It seems to be a randomly caused issue. Is everybody in this thread that’s seeing this issue trying to “connect to domain” via samba/openLDAP, or through Active Directory? I have never seen this particular issue in regards to AD, but then again I might be in an optimal setting where this just doesn’t happen.
If it’s only happening on samba/openLDAP and is only occurring relatively recently, did you perform OS updates? If you did, it’s quite possible something changed in the Samba source code which would be beyond my scope of understanding. It might even just be a new setting implemented that needs to be adjusted to be fixed.
I feel, more so, that this is unrelated to Domain Joining in and of itself, but rather a configuration issue/change that’s posing the problem.
-
Tom, BPSTravis… Thanks for the quick replies.
Yes, we recently updated Samba from 3.6.16 to v3.6.22
Also, Since this is a Windows 7 with Samba 3.x backend, and GPO support is not available until Samba 4.x (which is out now) we are using a product called Nitrobit to very nicely and easily implement policies to get us through until we can upgrade to Samba 4.x.
On boot, and just prior to the logon screen being presented, the Nitrobit client dialog pops up to show its progress. At this point it connects to a share on the server and reads its policies for the machine…
I am wondering if (same as Tom mentioned) that something in Samba changed in that update which may be keeping that connection opened, which is preventing the domain join.
Tom, what are the chances that the Fog service could be configured to issue a:
net use * /Delete /Y (or use other method)
to forcefully disconnect all shares prior to attempting to join the domain?
Or, maybe query any open connections and writ them to the log file to prove the theory?
We’d be VERY happy to test a FOG Service with that implemented to see if it fixes the issue.
Meanwhile, I will scan the Samba changelog to see if anything is glaringly obvious to me.
Thanks!
-
Tom, BPSTravis,
Nothing in the Samba changelogs from 3.6.16 to 3.6.22 jumps out at me as a possible cause, but that (the Samba update) IMHO is still my number one suspect. Can’t really drop back to an earlier version for two reasons, 1. .22 was a critical security patch, and 2, it is alive production environment
I have however, set up a virtual Windows 7 machine on their VMware cluster so I can quickly test imaging, domain joins, and/or any patches to the FOG service.
As part of testing I will be increasing the Samba logging levels but I suspect I will see the same error from the other side of the conversation.
Thanks again for any help
-
OK, here’s an update.
With the Nitrobit client removed and hence, no fileserver access prior to the FOG Service attempting the domain join, the Win7 client auto-joins the domain every single time.
I can even change the Win7 client’s name and take it out of the domain (at the same time) then reboot, and it will boot to local login prompt, pause, rename, reboot, then pause at a local login prompt, join domain, reboot, and stop at a domain login screen - exactly as expected.
So, since the Nitrobit client was on these Windows 7 machines from the start, it looks like it is surely some change in Samba. Perhaps it holds the share opened longer than it had in the past.
I am willing to provide any additional info, or test any patches etc. Let me know what I can do to help solve this.
I think I might be off to the Samba list to see if I can get someone to decipher the changelog and pinpoint the change that may be the cause of this.
Thanks!
-
Samba mailing list post fell on deaf ears (or blind eyes I guess
But!
THIS. IS. SOLVED!
(or at least worked-around)
So, as it was appearing to be, it was a timing issue.
Fileserver share was opened by Nitrobit client pre-logon screen, and was held opened for a bit (by WIn7, or Samba, not sure but suspect a change in upgraded Samba version to be the cause), then FOG Service tries to immediately join domain, join fails due to the “multiple connections…” issue.
Solution?
Set the FOG Service on Win7 to “Start delayed” \0/
This will cause it to start “approximately 2 minutes after system boots.”
I have tested this several times (10+) on the Win7 VM that I set up and, while it may take a little longer (up to 4 about additional mins), the Windows 7 workstation with the Nitrobit client installed on it goes throught the rename, reboot, domain join, reboot-to-domain-logon process flawlessly now - every time!
So my question is, I wonder what the Samba > v3.6.16 smb.conf option might be to alleviate this without having to modify the FOG Service settings?
Also, I wonder if the FOG Service install could be modified to either automatically set the service to “Delayed Start” or ask during the install:
“Do you have any services that connect to the Domain Controller pre-logon screen?” If yes, then set for delayed start, if no, no delayed start.
Possible other option is what I mentioned previously: FOG Service forcefully disconnects any server connections just prior to join attempt.
It is 11:30pm on a Friday night, and I am so done with this. Happy it is solved. Now to notify our client so everyone can rejoice!
Thanks Tom, thanks BPSTravis!
Whoops… Now it is 11:30AM… Forgot to click “Post Reply” before walking out of office triumphantly. heh
