Secure channel & thin client

[Guest]

Ok, I am having a major problem with Xpe thin clients and W2K3 domain. After
installing new client it will lose trust relationship to domaincontrollers
and wont log into domain. This can happen after a day or a month, its random.
The workstation will log error eventid 3210 and domaincontroller eventid
5722(check www.eventid.com for details). The problem can be fixed by
rejoining the domain but its very irritating as we have quite large amount of
workstations. I have been searching solution quite a time now and maybe it
has something to do with values under:
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type RefusePasswordChange as the registry entry name, and then press
ENTER.
5. On the Edit menu, click Modify.
6. In the Value data box, type a value of 1, and then click OK.
7. Quit Registry Editor.
I do that on all DC but I have always the same problem ????

 

[Guest]

I am seeing the same problem but with XP Pro, not XPe, does anyone have any
suggestions?

 

[Guest]

Mark, Are you using thin client or PC's ?
If you have problem with PC, verify the acces to the registry .

 

[Guest]

They're PC's,
There is access to the registry via regedit under and admin account... if
thats what you're asking...

 

[Guest]

Sorry mark, Have you try this :

1. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
2. On the Edit menu, point to New, and then click DWORD Value.
3. Type RefusePasswordChange as the registry entry name, and then press
ENTER.
4. On the Edit menu, click Modify.
5. In the Value data box, type a value of 1, and then click OK.
6. Quit Registry Editor.

But I never had the problem with the PC (configure with DHCP)

 

[Guest]

No I haven't tried it but I will today.......

Just out of curiousity what is the possible cause and what does this work
around do....

BTW Thanks so much for responding, this problem has been plauging us and we
still have no perm solution...

 

[KM]

Mark,

No I haven't tried it but I will today.......

Just out of curiousity what is the possible cause and what does this work
around do....

"Prevents a domain controller from accepting requests from workstations to change their computer account passwords.".

http://www.microsoft.com/resources/...s/2000/server/reskit/en-us/regentry/58441.asp

 

[Guest]

KM -

Will this reg fix apply even if I have the "Never Expire" option set. I'm
seeing the exact same thing as A Hotton. I know this is an XPe forum, but it
just so happens that this has been puzzling me for weeks. It's basically a
2k server domain controller and a mixed 2k and XP Pro based machines. At
random their computer accounts become corrupt and no longer allow us to log
in. We have to log out, log in locally, delete their computer accounts from
Active Dir, then rejoin them to the domain. You still think thats the issue?


Btw, you have been alot of help, and I thank you.

 

[KM]

Mark,

Actually, I sent you a wrong link. You should have received the link for DisablePasswordChange value:
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/regentry/32420.asp.

Anyway, your problem does not seem to be related to password issues.
What do you mean be "account corruption"? Do you think it is just a change in password or an account becomes inaccessible at all?

Read this thread: http://groups.google.com/groups?hl=en&lr=&c2coff=1&[email protected]
Even though it does not have a resolution, someone mentioned some things that can get corrupted in AD environment (LDAP entries).
Also verify if you are running "Certificate services" service on your client machines (AD will force a client certificate update
every week or so according to the policy set).

I am not an expert in AD environment. If anyone here is, please help Mark with the issue.
Otherwise, Mark, you are better off posting this to more appropriate NG.