Cannot access root shares (sysvol, netlogon ,etc) by using domain.local, but can if I use fqdn of server or IP.

Hugo Rosa
Hugo Rosa used Ask the Experts™
on
Hi,

Here is the current situation:

1- I can see list of shares if I access domain.local.
2- I cannot enter any share if I use domain.local (clicking from the list of shares). GPupdate is failing too...
3- If I use fqdn of server i can access each folder without issues.
4- If I use IP i can access each folder without issues.
5- nslookup of domain.local is ok
6- computers can join without issue to domain.
7-No errors in dfs (event viewer). But this does not disqualify dfs as the problem.
8- This was working a few days ago perfectly. In a previous setup the server was only AD / DC , no dns or dhcp involved. Recently we moved all the dns, dhcp , wins, etc to the core AD/DC server (same server im talking above), because we were having issues integrating with some other systems (user integrations).
9- Issues with integration / sync of AD cleared, but now this new problem arise. This cause suspect for dns issues , though i can resolve and ping anything.

Its been a few crazy hours, literally no sleep, maybe some of the real experts have an idea :D?

Windows Server 2012 R2. Workstations are Windows 7.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Will SzymkowskiSenior Solution Architect
Most Valuable Expert 2015
Top Expert 2015
Commented:
How many DC's do you have in your environment? Have you checked replicaiton?

repadmin /replsum
repadmin /showrepl
repadmin /bridgeheads
DCDiag /v

Also checking the logs on the DC specifically the "Directory Service Logs" each DC.

Also when you login to the DC open a command prompt and run "net share" <press enter>

Make sure that the NetLogon and Sysvol shares are shared out properly.

It is also possible that you might be required to perform an Authoritative Restore for Sysvol as well.
https://support.microsoft.com/en-us/kb/2218556


Will.

Author

Commented:
Everything passed ,except the following:
 Starting test: MachineAccount
    Checking machine account for DC SERVER1 on DC SERVER1.
    The account SERVER1 is not trusted for delegation.  It cannot
    replicate.
    The account SERVER1 is not a DC account.  It cannot replicate.
    Warning:  Attribute userAccountControl of SERVER1 is:
    0x11000 = ( WORKSTATION_TRUST_ACCOUNT | DONT_EXPIRE_PASSWD )
    Typical setting for a DC is
    0x82000 = ( SERVER_TRUST_ACCOUNT | TRUSTED_FOR_DELEGATION )

Could this be causing such sysvol access issues?


Answering your question: just one dc. Thank your for answering.
Will SzymkowskiSenior Solution Architect
Most Valuable Expert 2015
Top Expert 2015

Commented:
Yes this is the issue with your replicaiton. Can you also run netdom query fsmo and netdom query dc.

You will need to follow the link i have provided above and make sure that you perform an authoritative restore of Sysvol.

Just curious when you ran net share where the Sysvol and Netlogon shared out?

Will.
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Author

Commented:
net share, executed inside dc:

SYSVOL       C:\Windows\SYSVOL\sysvol        Logon server share

NETLOGON     C:\Windows\SYSVOL\sysvol\THEDOMAIN.local\SCRIPTS

The problem is only for workstations. Will follow the link and see if it solve it.

Author

Commented:
C:\Windows\system32>netdom query dc
List of domain controllers with accounts in the domain:

The command completed successfully.
Will SzymkowskiSenior Solution Architect
Most Valuable Expert 2015
Top Expert 2015

Commented:
List of domain controllers with accounts in the domain:
Did you remove the domain controllers that were listed due to security purposes or was nothing present?

If nothing was present then you need to perform an Authoritative Restore of Sysvol.

Will.

Author

Commented:
Did the  authoritative , still >netdom query dc gave me nothing as results. Any other process that should be done after doing authoritative?
Will SzymkowskiSenior Solution Architect
Most Valuable Expert 2015
Top Expert 2015

Commented:
Also did you run netdom query fsmo? What you might want to do is Seize the Roles back to this DC.

Will.

Author

Commented:
C:\Windows\system32>netdom query fsmo
Schema master               SERVER1.THEDOMAIN.LOCAL
Domain naming master        SERVER1.THEDOMAIN.LOCAL
PDC                         SERVER1.THEDOMAIN.LOCAL
RID pool manager            SERVER1.THEDOMAIN.LOCAL
Infrastructure master       SERVER1.THEDOMAIN.LOCAL
The command completed successfully.
Will SzymkowskiSenior Solution Architect
Most Valuable Expert 2015
Top Expert 2015

Commented:
Have you tried rebooting the DC? Also are there anything in the logs after you have run the authoritative restore?

Will.

Author

Commented:
Something is wrong with this DC. I mean why would I be able to access it via server1.thedomain.local and click each share, and when I do the same for thedomain.local i see the shares but i get denied!
Will SzymkowskiSenior Solution Architect
Most Valuable Expert 2015
Top Expert 2015

Commented:
Yes you are correct, there is something definitely wrong with this DC. When you run netdom query fsmo you should see ALL DC's that are in your domain. If you are not seeing anything then there is something definitely wrong. Do you have a system state backup of the DC?

You might have to restore the entire server using the Authoritative Restore method.

Will.

Author

Commented:
C:\Windows\system32>netdom query fsmo
Schema master               SERVER1.THEDOMAIN.LOCAL
Domain naming master        SERVER1.THEDOMAIN.LOCAL
PDC                         SERVER1.THEDOMAIN.LOCAL
RID pool manager            SERVER1.THEDOMAIN.LOCAL
Infrastructure master       SERVER1.THEDOMAIN.LOCAL
The command completed successfully.


netdom query fsmo show all correctly, howver netdom query dc dont.
Problem solved.

A.
To add the SERVER_TRUST_ACCOUNT flag to the UserAccountControl attribute

Start ADSIEDIT.MSC on the console of DC missing the SERVER_TRUST_ACCOUNT reported by DCDIAG.
Right-click ADSI Edit in the top left pane of ADSIEDIT.MSC and chose Connect to....
Within the Connection Settings dialog:
Click Select a well known Naming Context and chose Default naming context (that is, the computer account’s domain partition).

Click Default (Domain or server that you are logged on to).

Click OK.

<<Insert ADDS_ADSIEditConnectionSettings>>
In the domain naming context, locate and then right-click the domain controller computer account and chose Properties.
Double-click the userAccountControl attribute and record its decimal value.

-Microsoft instructs after the above steps to do some add in value, etc. But this specific value solved the problem for me:
532480

the above value add: SERVER_TRUST_ACCOUNT flag.

B.
To add the TRUSTED _FOR_DELEGATION flag to the userAccountControl attribute

Start Active Directory Users and Computers (DSA.MSC) on the console of the DC tested by DCDIAG.
Right-click the DC computer account, and then click Properties.
Click the Delegation tab.
Click Trust this computer for delegation to any service (Kerberos only), and click OK.

These two , specially (A.) solved the sysvol share issue when accessing \\exampledomain.local\sysvol whose access is needed to read and apply policies.

Author

Commented:
dcdiag /v     <-super helpful thanks Will

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial