Converting Windows XP client from Novell to Microsoft
Yesterday and today, I spent quite some time on a client that in the past logged in to a NetWare NDS environment and that should be changed to no longer log into NDS but to Active Directory instead. In itself not quite a difficult job: remove the Novell Client32, install Client for Microsoft Networks and that should be it. This is true, just to a certain level, I discovered...
Spent really quite some time trying to find out why Group Policies were not applied and software was not distributed. Event IDs 1030 and 1058 were logged at the client site, indicating that some part of the SYSVOL-folder on the DC could not be read. First, I learned that there is a hotfix for that as mentioned in Microsoft KBA 810907, but after applying that one my problem remained.
Further googling brought me to Microsoft KBA 314494 and that one did the trick. What had happened?
As I said, this client used to login to an NDS-environment using Client32. Client32 has lots of performance issues, especially in multi-redirector situations (a redirector is used to connect to a certain server environment; multi-redirector means that the client connects both to Novell and Microsoft (or other) servers). There is a Novell TID on how to improve performance in such situations and of the tips they do is to explicitly DISABLE the DFS Client in Windows 2000/XP by modifying the DisableDFS registry key (in HKLM\SYSTEM\CurrentControlSet\Services\MUP, to be exact).
Exactly that reproduces the problem that I had, as follows: the SYSVOL-folder on a domain controller is replicated automatically to other DCs using DFS. Clients need a DFS Client in order to be able to reach the SYSVOL-share on the DC. By disabling the DFS Client in Windows in order to improve performance to the NDS environment, this new problem was introduced.
So, what is all boils down to is that when you ever need to connect your existing Novell client to an Active Directory environment, first check the DisableDFS regkey and make sure it is set to 0.
Spent really quite some time trying to find out why Group Policies were not applied and software was not distributed. Event IDs 1030 and 1058 were logged at the client site, indicating that some part of the SYSVOL-folder on the DC could not be read. First, I learned that there is a hotfix for that as mentioned in Microsoft KBA 810907, but after applying that one my problem remained.
Further googling brought me to Microsoft KBA 314494 and that one did the trick. What had happened?
As I said, this client used to login to an NDS-environment using Client32. Client32 has lots of performance issues, especially in multi-redirector situations (a redirector is used to connect to a certain server environment; multi-redirector means that the client connects both to Novell and Microsoft (or other) servers). There is a Novell TID on how to improve performance in such situations and of the tips they do is to explicitly DISABLE the DFS Client in Windows 2000/XP by modifying the DisableDFS registry key (in HKLM\SYSTEM\CurrentControlSet\Services\MUP, to be exact).
Exactly that reproduces the problem that I had, as follows: the SYSVOL-folder on a domain controller is replicated automatically to other DCs using DFS. Clients need a DFS Client in order to be able to reach the SYSVOL-share on the DC. By disabling the DFS Client in Windows in order to improve performance to the NDS environment, this new problem was introduced.
So, what is all boils down to is that when you ever need to connect your existing Novell client to an Active Directory environment, first check the DisableDFS regkey and make sure it is set to 0.
Reacties