Cannot access CIFS shares after installing 2008R2 server.

Thanks....found this while searching around for ETA158629..

"

Fix       

To allow the CIFS server alias to function just as the normal CIFS server name, certain actions must be taken.  First, a CNAME DNS alias must be created in DNS.  Then the workaround for Celerra  ETA emc158629 must be applied.

After, the SPNs will have to be generated on the domain controller by a domain administrator.  If Windows 2008 is used, the command prompt must be run as administrator because of User Account Control

Fix       

To allow the CIFS server alias to function just as the normal CIFS server name, certain actions must be taken.  First, a CNAME DNS alias must be created in DNS.  Then the workaround for Celerra  ETA emc158629 must be applied.

After, the SPNs will have to be generated on the domain controller by a domain administrator.  If Windows 2008 is used, the command prompt must be run as administrator because of User Account Control

"

Does that look right to you? I was searching for ETA emc158629 and couldn't find instructions on how to apply this. Could you help me with that?

Also, what is this thing about generating SPNs? Is that needed?

ETA emc158629 is  https://emc--c.na5.visual.force.com/apex/KB_ETA?id=kA37000000000G6

The command to disable strict name checking on the datamover  is:

$ server_param server_2 -f cifs -m LanmanServer.disableNameChecking -v 1

A datamover reboot is needed after changing this parameter

Thanks @Peter_EMC

Changed the value last night and rebooted the data mover.

After doing so, I went back to my DCs and restarted the AD service. Unfortunately, 15 minutes later, the error came back up.

Checked the Celerra one more time to make sure my changes were in place:

$ server_param server_2 -f cifs -info LanmanServer.disableNameChecking -v

server_2 :

name = LanmanServer.disableNameChecking

facility_name = cifs

default_value = 0

current_value = 1

configured_value = 1

user_action = reboot DataMover

change_effective = reboot DataMover

range = (0,1)

description = Disables checking of the server's principal name of the client's kerberos ticket.

detailed_description

When set to 1, this parameter disables the control of the server's principal name of the client's kerberos ticket. The client is then allowed to connect with a DNS alias (please refer to Microsoft article 281308). When set to 0, the client is only allowed to connect using the primary computer name.

$

Do you have any other ideas, or do I have to set/verify something else on some other side of things?

IMHO at this point your best way to get this resolved is to take a network trace when the problem is happening and turn it over to EMC support via a service request

Yeah…tried that. They keep asking for support materials and I keep sending it over. They really aren’t that much help! Argh! I swear, this forum is wayyy more useful than them!

Looked into this EMC eta a lil bit more and it says that, “This solution is only applicable if SPNs were manually added for DNS aliases.” Which I have never created. But it was a valiant effort!

For kicks, I tried to manually created these SPNs so that this eta would be the fix, but when I try to create a SPN record, I get:

C:\Users\admin>setspn -R fileserver

FindDomainForAccount: DsGetDcNameWithAccountW failed!

Could not find account fileserver

Any other ideas?

Thanks again!

Please follow Kolas advice (Posting 32) and read KB article 11282 aka emc204608 how to create SPN's on the Windows machines connecting to the aliased CIFS server

setspn -R is the wrong option (it is reseting a SPN)

Seems like reseting a non existing SPN is not working.

The -L will list all SPNs

> setspn -L ja-sm-storage1

Analyze the output, you need to create the records starting with cifs and host manually, replacing the ja-sm-storage1 with your alias fileserver. I guess this will be 4 entries to create (2 cifs and 2 host, fully qualified and unqualified)

use the -A to create the alias, one example would be

> setspn -A host/fileserver ja-sm-storage1

Create all needed alias SPNs!

Create an alias ("fileserver") also on the datamover (see server_cifs command), the command would be like (no line breaks!):

$ server_cifs server_2 -add

compname=ja-sm-storage1,domain=MyNetwork.NET,alias=fileserver,interface=Production_Interface_0

Thanks for the suggestions Peter...this is what I've done so far..

1. Read 11282 and listed out my SPNs. Here is my result:

         C:>setspn -L ja-sm-storage1

          Registered ServicePrincipalNames for CN=ja-sm-storage1,OU=Computers,OU=EMC Celerra,DC=MyNetwork,DC=net:

             cifs/ja-sm-storage1.mynetwork.net

             cifs/ja-sm-storage1

             host/ja-sm-storage1.mynetwork.net

             host/ja-sm-storage1

2. Then created additional host and cifs SPNs, according to the article. (BTW, in the KB, it shows NFS SPNs. Is that necessary?)

        host/fileserver.mynetwork.net

        host/fileserver

        cifs/fileserver

        cifs/fileserver.mynetwork.net

3. Created the alias you suggested in your previous comment

So what I noticed now, is that clients will be able to connect to the share via \\fileserver but will NOT be able to access the share via \\IPAddress still. Why is that the case?

Also, we have a Xerox network printer that has a 'Scan to network' feature that uses SMB to scan to \\fileserver\scans but still cannot access that share.

The current workaround is the turn off my newest AD server and everything will work just fine.

JAssociates wrote: So what I noticed now, is that clients will be able to connect to the share via \\fileserver but will NOT be able to access the share via \\IPAddress still. Why is that the case?

When using \\IP, then Kerberos is not used (see http://support.microsoft.com/kb/322979 ) but the old NTLM

I assume your AD is configured only for using kerberos but not NTLM.

For your "Scan to network" issue.

What Port do you use? 445?

What login credentials did you configure? I think "Authenticated User and Domain" is the way to go.

(domain name in CAPS)

Verify the access of this user by mapping the share and writing a file as this user.

Do you know where/how to check to see if my network is not configured for NTLM?

A big concern for me is that why does my network and cifs access work perfectly fine with only one of my original DCs powered on? \\ip address, \\alias, and \\storage name all work just fine and no users have problems. Scanner works fine too!

But as soon I as turn on AD services on any new DC (I've tried with more than 1 DC), the access problems will start to come up.

Head scratcher, but thanks for all the help thus far!

From your first posts:

"I've deployed a new Windows 2008R2 server in an existing domain with 2 other non-R2 2008 DCs,"

You are exploring the differences between 2008R2 DCs and older ones.

If you do not want this, than do not use 2008 R2, but the same "non-R2 2008" OS.

Yeah, that makes sense. I wanted to isolate the issue, so I unretired an old NON R2 server to see if the issue is still around, and it is.

I didn’t technically unretire it though. With my older non R2 server, I pretty much just removed DC roles when I say I ‘retired’ it. When I unretired it, I just re-added DC roles (AD, DNS, and DHCP) without reinstalling any software. But the issue happens when that server’s AD services are started. If I stop the services, thereby only using 1 DC (the original), the issue goes away…

I wonder if you introduce a new DC to the environment (which I kind of did), if I have to configure something with the Celerra or change some GPO setting?

what windows version is this unretired server using and what version is the old server using

What version on the server is running in the "working domain" and what versions are no longer working?

Both servers are running Windows Server 2008 non R2…we don’t have any DCs running anything earlier than that.

Old server (server 1) : non R2

Unretired (server 2) : non R2

New (server 3) : R2.

For now, I’ve shut off server 3 and only dealing with server 1 & 2 to eliminate any type of R2 interference..