Imported users cant access 2008R2 share via CNAME from Win8
We are currently testing Win8 and have an issue where some users cant access a particular 2008R2 file server. But only when trying to use a CNAME record. (from logon script or win explorer)
These same users are fine running Win7-64/XP-32/Vista. All CNAMEs resolve ok from win8 when using Ping.
Servers: FILE Win2008R2 bwjobs.domain as CName for Server04.domain (built 2011)
MAIL win2008R2 bwmail.domain as CName for Server01.domain (built 2010)
Client: Win8 Pro.
1. So when an 'old' user (ie me) log's on to the domain, the drive mapping fails for shares on bwjobs. When a 'new' user (someone created since the the system was installed 2yrs ago), log's on, all mapping works as currently for XP/Win7 users. I believe the 'old' users were imported into a new AD forest for the new 2008R2 domain, from an SBS2003 domain. Not migrated.
2. File server access is different....
2.1 For my logon, From explorer, \\bwjobs (the cname) throws a logon dialog. And wont accept credentials.
2.2 yet typing \\server01 (the real name) shows me the available shares as expected.
2.3. Yet \\bwmail (cname) shows me the std shares for an Exchange server. (from Win8)
4. I cant see how how the user's AD properties are different. (at least through the UI)
Any ideas on how to check the user properties and how the server properties for shares may be different ? (Note mapping in Win7 works for all users and servers)
The servers both have DisableStrictNameChecking = 1 in Lanman params, DisableLoopbackCheck not set in either, and no items in BackConnectionHostNames. (both running production so restarts are problemattic with backup windows)
These same users are fine running Win7-64/XP-32/Vista. All CNAMEs resolve ok from win8 when using Ping.
Servers: FILE Win2008R2 bwjobs.domain as CName for Server04.domain (built 2011)
MAIL win2008R2 bwmail.domain as CName for Server01.domain (built 2010)
Client: Win8 Pro.
1. So when an 'old' user (ie me) log's on to the domain, the drive mapping fails for shares on bwjobs. When a 'new' user (someone created since the the system was installed 2yrs ago), log's on, all mapping works as currently for XP/Win7 users. I believe the 'old' users were imported into a new AD forest for the new 2008R2 domain, from an SBS2003 domain. Not migrated.
2. File server access is different....
2.1 For my logon, From explorer, \\bwjobs (the cname) throws a logon dialog. And wont accept credentials.
2.2 yet typing \\server01 (the real name) shows me the available shares as expected.
2.3. Yet \\bwmail (cname) shows me the std shares for an Exchange server. (from Win8)
4. I cant see how how the user's AD properties are different. (at least through the UI)
Any ideas on how to check the user properties and how the server properties for shares may be different ? (Note mapping in Win7 works for all users and servers)
The servers both have DisableStrictNameChecking = 1 in Lanman params, DisableLoopbackCheck not set in either, and no items in BackConnectionHostNames. (both running production so restarts are problemattic with backup windows)
Can any user connect to the share via CNAME? This has been disabled by default since server 2003. There has to be a modification to the server registry for this to work. The link below is for server 2003, but I have found it is applicable to server 2008.
http://support.microsoft.com/default.aspx?scid=kb;en-us;281308
http://support.microsoft.com/default.aspx?scid=kb;en-us;281308
ASKER
1. the error is only on Win8. connections are fine from Win7, etc, for ALL users.
2. "new" users work fine on Win8.
3. the users were bulk imported into a new domain somehow (from CSV or something), rather than a new DC added to use old domain.
4. The DisableStrictNameChecking = 1 has been set for a couple of years, as per the last paragraph of Q.
2. "new" users work fine on Win8.
3. the users were bulk imported into a new domain somehow (from CSV or something), rather than a new DC added to use old domain.
4. The DisableStrictNameChecking = 1 has been set for a couple of years, as per the last paragraph of Q.
If users were created with a bulk import from CSV, then its functionally the same as adding them one by one, however it could be that "something else" was done at the same time.
I would suggest following these tests, reboot between each step.
With a clean build of Win 8 (never joined to the domain, see if you can connect to the CNAME share, you will be prompted for a password, but it should be capable of connecting, if it does not, then it is a GPO that is setting something that allows the connection, if it works reboot and and see if you can connect again.
Join the computer to the domain, but again logon with the local account and again check if you can connect
Logon to the computer with a "broken" account and check that you cannot connect to the CNAME
Again logon with a local account and test
Logon to the computer with a working account and check that you can connect without being prompted for a password
Again logon with a local account and test
I have a feeling that it might be a GPO settings that is being applied that is allowing the CNAME to work.
I would suggest following these tests, reboot between each step.
With a clean build of Win 8 (never joined to the domain, see if you can connect to the CNAME share, you will be prompted for a password, but it should be capable of connecting, if it does not, then it is a GPO that is setting something that allows the connection, if it works reboot and and see if you can connect again.
Join the computer to the domain, but again logon with the local account and again check if you can connect
Logon to the computer with a "broken" account and check that you cannot connect to the CNAME
Again logon with a local account and test
Logon to the computer with a working account and check that you can connect without being prompted for a password
Again logon with a local account and test
I have a feeling that it might be a GPO settings that is being applied that is allowing the CNAME to work.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The crucial information that this server was also a DC had been missed from the original description...
ASKER
Found real problem & solution independently. Should have be able to do this before posting !
I don;t know what you mean by "imported" instead of "migrated".