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!
Cannot access root shares (sysvol, netlogon ,etc) by using domain.local, but can if I use fqdn of server or IP.
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.
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.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
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.
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.
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.
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.
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.
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.
net share, executed inside dc:
SYSVOL C:\Windows\SYSVOL\sysvol Logon server share
NETLOGON C:\Windows\SYSVOL\sysvol\T
The problem is only for workstations. Will follow the link and see if it solve it.
SYSVOL C:\Windows\SYSVOL\sysvol Logon server share
NETLOGON C:\Windows\SYSVOL\sysvol\T
The problem is only for workstations. Will follow the link and see if it solve it.
C:\Windows\system32>netdom
List of domain controllers with accounts in the domain:
The command completed successfully.
List of domain controllers with accounts in the domain:
The command completed successfully.
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.
Did the authoritative , still >netdom query dc gave me nothing as results. Any other process that should be done after doing authoritative?
Also did you run netdom query fsmo? What you might want to do is Seize the Roles back to this DC.
Will.
Will.
C:\Windows\system32>netdom
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.
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.
Have you tried rebooting the DC? Also are there anything in the logs after you have run the authoritative restore?
Will.
Will.
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!
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.
You might have to restore the entire server using the Authoritative Restore method.
Will.
C:\Windows\system32>netdom
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.
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_ADSIEditConnectionSet
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\sysv
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_ADSIEditConnectionSet
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\sysv
Premium Content
You need an Expert Office subscription to comment.Start Free Trial