Intermittent Access is Denied error when accessing EMC CIFS share after introducing 2008 R2 DC into domain

I recently learned about how DNS fails down to the alternate entries and doesn't return unless the current one fails. Also nslookup will use the primary DNS even if you have failed over to one of the alternate DNS servers.

So, try doing nslookup on filesrv and specify each of your alternate DNS servers in turn to see if one doesn't have the record correct.

Also try \\filesrv.mycompany.net if that works, the primary DNS suffix if the computer could have issues

Make sure the IPs this DHCP server is allocated are allowed to access the CIFS share.

The IPs in the new DHCP might be outside the range authorized on the CIFS share.

Look at dcdiag to make sure there are no Dcs out of sync if the rejection is based on user credential.

@aarontomosky
would DNS still be an issue if these affected clients can ping the IP address and the alias? Ping tests are successful to both. they just get an Access is Denied error when trying to access the files. If we try to connect via "emc-san", we can ping and access files just fine. What else do you think I can look at?

@arnold
The IPs assigned by this new server are the same range of DC #2 (which is currently turned off). This new server was supposed to take over the exact responsibilities of server #2. Before I implemented this new R2 server, everything was working just fine.
Also ran dcdiag dns test and everything passed.

Anything else I can look at?

What happens when you try
 \\filesrv.mycompany.net

You should not have turned off DCs.  My guess is that at times the authentication requests are being sent to the DC that is turned off and upon receiving no response the access is denied.

@arnold
but shouldn't turning off a DC not have an effect if I have multiple DCs running? I thought that was the point of the redundancy so that there is a failover

@aarontomosky
If I try to access \\fileserv.mycompany.net, I get the same error as \\fileserv. It's pingable, but I get prompted for credentials and says Access is Denied.


Here's something else that I found out. The problem is somewhat intermittent. If I reboot the new server, everyone will be able to connect for a couple of minutes, but then some users will eventually get that error message after a while.

Does that help with anything?

For the printing thing, to print to an alias you have to tweak a setting
http://support.microsoft.com/kb/870911

@aarontomosky
I should clarify...printing itself works fine. It's the scan to file aspect where our printer scans a document and then uploads it to our file server. It uses the SMB protocol to connect via DNS name to our fileserver to upload the scan. That's not working either, and very similar to our affected users, in that it cannot access the share.

Yes, however there are transition issue. Are all DC's setup as GC?
The comment was just one possibility.  You've not identified what or how access is being denied. I.e. user credentials mismatch,, system level access IP/ACL.
Des the user who has an issue from workstation A has the same issue on workstation B?

Check your Firewall on this server.

do you know what I should be checking for?

One of the DCs denying EMC access to validate auth.

Make sure your windows firewall is set to accomodate domain services. As a test, you can disable the firewall to see if the problem resides.

http://support.microsoft.com/kb/179442

yes, I disabled the firewall temporarily and it is still happening. If I didn't point it out before, this problem is somewhat intermittent. When the server starts up, there aren't any issues, but as time goes by, some users will be denied access. It's almost as if there is some sort of connection limit, and once that limit is hit, access is denied. If I reboot the server, the same pattern happens.

Then,  it would appear that DC promotion into the domain didn't go well and you have two separate domains. This happens when a server doesn't see the domain upon being promoted into the domain. Usually this is caused by not getting DNS straight and speaking to this server prior to promoting it into the domain.

Use the DCdiag tool to investigate. DCdiag would show the new server AND your old PDCe holding the five Flexible Single Master of Operations (FSMO) roles. The fact that DCreplications appear fine would lead me to believe DC promotion of this new system DID go well. So, this is most likely not the case.

Oh, thanks for that idea.

So I wanted to check the domain naming master role and saw something that I think might be suspicious. I figured I would post a screenshot just in case.

So on Server#3 (the new one), I went to AD Domain and Users, right clicked on it, and selected "Operations Master..."

The following image is what I found on it. Just to clarify, "JA-DC1" is my first DC (Server 2008R1).

If I'm logged onto Server #3, shouldn't I be able to change to role to that server? Meaning that shouldn't server #3 be listed in the bottom field?

Also, per your advice, i just ran a dcdiag /test:knowsofroleholders /v and here are my results:

C:\Users\admin>dcdiag /test:knowsofroleholders /v

Directory Server Diagnosis

Performing initial setup:
   Trying to find home server...
   * Verifying that the local machine ja-dc3, is a Directory Server.
   Home Server = ja-dc3
   * Connecting to directory service on server ja-dc3.
   * Identified AD Forest.
   Collecting AD specific global data
   * Collecting site info.
   Calling ldap_search_init_page(hld,CN=Sites,CN=Configuration,DC=mynetwork
,DC=net,LDAP_SCOPE_SUBTREE,(objectCategory=ntDSSiteSettings),.......
   The previous call succeeded
   Iterating through the sites
   Looking at base site object: CN=NTDS Site Settings,CN=mynetwork,CN=Sites
,CN=Configuration,DC=mynetwork,DC=net
   Getting ISTG and options for the site
   * Identifying all servers.
   Calling ldap_search_init_page(hld,CN=Sites,CN=Configuration,DC=mynetwork
,DC=net,LDAP_SCOPE_SUBTREE,(objectClass=ntDSDsa),.......
   The previous call succeeded....
   The previous call succeeded
   Iterating through the list of servers
   Getting information for the server CN=NTDS Settings,CN=JA-DC1,CN=Servers,CN=J
umpAssociates,CN=Sites,CN=Configuration,DC=mynetwork,DC=net
   objectGuid obtained
   InvocationID obtained
   dnsHostname obtained
   site info obtained
   All the info for the server collected
   Getting information for the server CN=NTDS Settings,CN=JA-DC3,CN=Servers,CN=J
umpAssociates,CN=Sites,CN=Configuration,DC=mynetwork,DC=net
   objectGuid obtained
   InvocationID obtained
   dnsHostname obtained
   site info obtained
   All the info for the server collected
   Getting information for the server CN=NTDS Settings,CN=ja-dc3,CN=Servers,C
N=mynetwork,CN=Sites,CN=Configuration,DC=mynetwork,DC=net
   objectGuid obtained
   InvocationID obtained
   dnsHostname obtained
   site info obtained
   All the info for the server collected
   * Identifying all NC cross-refs.
   * Found 3 DC(s). Testing 1 of them.
   Done gathering initial info.

Doing initial required tests

   Testing server: mynetwork\ja-dc3
      Starting test: Connectivity
         * Active Directory LDAP Services Check
         Determining IP4 connectivity
         * Active Directory RPC Services Check
         ......................... ja-dc3 passed test Connectivity

Doing primary tests

   Testing server: mynetwork\ja-dc3
      Test omitted by user request: Advertising
      Test omitted by user request: CheckSecurityError
      Test omitted by user request: CutoffServers
      Test omitted by user request: FrsEvent
      Test omitted by user request: DFSREvent
      Test omitted by user request: SysVolCheck
      Test omitted by user request: KccEvent
      Starting test: KnowsOfRoleHolders
         Role Schema Owner = CN=NTDS Settings,CN=JA-DC1,CN=Servers,CN=mynetwork,CN=Sites,CN=Configuration,DC=mynetwork,DC=net
         Role Domain Owner = CN=NTDS Settings,CN=JA-DC1,CN=Servers,CN=mynetwork,CN=Sites,CN=Configuration,DC=mynetwork,DC=net
         Role PDC Owner = CN=NTDS Settings,CN=JA-DC1,CN=Servers,CN=mynetwork,CN=Sites,CN=Configuration,DC=mynetwork,DC=net
         Role Rid Owner = CN=NTDS Settings,CN=JA-DC1,CN=Servers,CN=mynetwork,CN=Sites,CN=Configuration,DC=mynetwork,DC=net
         Role Infrastructure Update Owner = CN=NTDS Settings,CN=JA-DC1,CN=Servers,CN=mynetwork,CN=Sites,CN=Configuration,DC=mynetwork,DC=net
         ......................... ja-dc3 passed test KnowsOfRoleHolders
      Test omitted by user request: MachineAccount
      Test omitted by user request: NCSecDesc
      Test omitted by user request: NetLogons
      Test omitted by user request: ObjectsReplicated
      Test omitted by user request: OutboundSecureChannels
      Test omitted by user request: Replications
      Test omitted by user request: RidManager
      Test omitted by user request: Services
      Test omitted by user request: SystemLog
      Test omitted by user request: Topology
      Test omitted by user request: VerifyEnterpriseReferences
      Test omitted by user request: VerifyReferences
      Test omitted by user request: VerifyReplicas

      Test omitted by user request: DNS
      Test omitted by user request: DNS

   Running partition tests on : ForestDnsZones
      Test omitted by user request: CheckSDRefDom
      Test omitted by user request: CrossRefValidation

   Running partition tests on : DomainDnsZones
      Test omitted by user request: CheckSDRefDom
      Test omitted by user request: CrossRefValidation

   Running partition tests on : Schema
      Test omitted by user request: CheckSDRefDom
      Test omitted by user request: CrossRefValidation

   Running partition tests on : Configuration
      Test omitted by user request: CheckSDRefDom
      Test omitted by user request: CrossRefValidation

   Running partition tests on : mynetwork
      Test omitted by user request: CheckSDRefDom
      Test omitted by user request: CrossRefValidation

   Running enterprise tests on : mynetwork.net
      Test omitted by user request: DNS
      Test omitted by user request: DNS
      Test omitted by user request: LocatorCheck
      Test omitted by user request: Intersite

JADC1 held the FSMO roles prior to the introduction of the new server. What this tells me is, your server recognized the domain, prior to being promoted into the domain.

You said JADC1 is a R1 server. Do you mean 2008 standard (I thought 2008 was all R2 but may be wrong).

If this is a 2008 standard server (without R2) than this is your problem. You didn't prep the domain for mixed mode operations, prior to promoting the R2 server into a Standard Server domain.

This would include the AD prep and Domain Prep, prior to DC promotion of this new server into the domain.

Again, I thought all 08 servers were R2 servers. There is a difference in authentication.

Plausible fix (if not an R2 server on JADC1):
Since the promotion went well, On the new server run DCpromo again. that eliminates the AD database and removes it as a recognized domain server. Then, run AD prep and Domain prep prior to promoting this new server back into the domain.

JADC1 is 2008 Standard, and NOT R2. I hope that clears up any question...

As for the mixed mode thing, are you referring to the functional level? If so, I'm running on the 2003 level. Do you think that is what is causing this intermittent fileshare access to my EMC unit?

Yes, but you have to Domain Prep and AD (active Directory) prep the exhisting domain to introduce an R2 DC into the domain. Otherwise, I could see the differences in the two AD schemas, causing the issues you are exhibiting.

When DC#4 (the other one in our branch office) was introduced last year, I ran ADPrep.

I ran it once again when I unboxed DC#3 in antipation, but got an error saying it was not needed.

I have never used Mixed mode operations. Instead, I rebuilt small domains with server upgrades and replaced all servers (including hardware) to change out domain controllers. For this, I think we should ask for additional assistance from other EE experts on how to prep a domain for mixed mode operations... I will initiate the additional request for attention.

For All experts that follow:
This is a mixed mode domain with 03 server standard, 08 server standard, and trying to introduce an 08 server R2. I don't believe the domain was prepared for R2, prior to the introduction to 08 R2 server and therefore we are running into problems with authentication on the new server.

There is nothing to it.  You can have a mix of 2003/2000 in a 2000 domain (no NT),
2003/2008/R2 in a windows 2003 domain no Windows 2000 DCs allowed.
With a windows 2008 DC, the issue is whether the EMC access to AD is supported with this DC.

The builtin windows 2008 firewall restriction may require a secure channel access to the AD which the EMC does not support or is not configured for.
Adjusting the windows 2008 Configuration to allow unsecure access to LDAP might help.

Configuring EMC to access with LDAP might allow it access.
Use wireshark on the windows 2008 DC to capture packets sent from the EMC.  See whether it sees requests but without matching responses.

So the new server 08serverR2 currently has its firewall turned completely off for this troubleshooting. but yet, users still get "access is denied" issues once the server has been turned on for a while..

Is there any other configuration EMC requires for a DC to connect to it?

Adprep and domainprep was used when I introduced server #4 (dc in branch office). Coincidentally, server #4 is also 08serverR2 and does not have any connectivity issues to the EMC.

sorry for the bump, but any ideas on what to do now?

try using wireshark to monitor traffic from the EMC in an effort to see why the reqests it sends are not received, are not responded to.

Do you have access to EMC support or the vendor through whom you purchased it?

So I decided to turn off the new DC (2008R2) and power up the old R1 server (which used to be my backup DC, and was fully functional). Since then, I have removed the DC roles (DHCP, DNS, and AD) and today I readded the roles. Added DHCP, DNS, and then ran DCPROMO to add AD, in that order.

So now I have effectively taken out the R2 server, but users who connect to this R1 server still cannot access the shares. I should point out that users to connect to my primary DC (R1) still connect just fine.

So now that we've ruled out R2 being the culprit, why is it that access to the EMC CIFS shares don't work correctly whenever I add a new DC to the mix?

When you power up an old DC that was likely tombstoned, your AD is not synchronized.  Queries hit one DC may get a different answer. The servers query randomly as well.  If SID changed I.e. you deleted/recreated accounts for usernames, you have a SID discrepancy on the fileserver and will be allowed/matched on the old DC while are being mismatched with the newer.

All the above is a guesstimate based on your description of the environment.

I don't believe the SID of this server changed it all. I never unjoined it from the domain, or renamed it or anything. The only change I did was remove the roles and readded them.

Maybe I'm missing something really simple...is there some sort of link I have to establish between the DC and EMC unit? Is there a permission that I simply forgot?

This is mostly over my head, but what kind of cert does your dc have? Self signed, wildcard, multiple names, or just plain single address?

The EMC must be able to query the AD.  If your EMC setup uses LDAP, you must make sure hat your windows 2008 system has the advanced firewall settings to allow non-SSL access to ldap 389.
Make sure it does not require secure access.

Alternatively, you might be able to configure EMC to only deal with one dC, but that will eliminate any fault handling. I.e if this DC goes down all access to the shares will be lost.

Not sure whether the EMC includes troubleshooting tools where you can test auth queries against specified DC to see what the issue is.

Using wireshark on the 2008 DC targeting/filtering rules the EMC as the source or destination to see whether the win2k8 sees the request and if so sends a response.

arnold,

So I figured that by re-enabling DC roles on my server#2, everything would work fine again. If it was a firewall thing, then the setting would have stuck around from before, right?

It worked a month ago, and now the only thing I've changed was removing roles and readding them.

There are many things that can happen between then and now including a security update that reset a parameter on which your setup relied.
I.e. you enabled non SSL access to the LDAP por ton the DC in question, a security updated the registry/firewall setting.

To the point aarontomosky raised, see whether your EMC had a certificate assigned for the purpose of authenticating to the AD DC that may have expired.

went to the source for my answer