Tech Blog

Had some strange issues recently where some group polices weren’t populating to certain sites.

i.e. you’d logon to a new device on a site and the work folders GPO wouldnt apply, after spending 5 minutes looking at RSOP.MSC I could see the policy just wasnt applied, at all.

So after some digging on the domain controller and googling events in the event viewer I found:

https://support.microsoft.com/en-gb/help/2958414/dfs-replication-how-to-troubleshoot-missing-sysvol-and-netlogon-shares

Which lead me to this nifty command to check the sysvol folder:

For /f %i IN ('dsquery server -o rdn') do @echo %i && @(net view \\%i | find "SYSVOL") & echo

As you can see from the above, all looks ok!!!

So now lets have a look-see at the DFS replication:

For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state

Run it and look for the “state”, the  values can be any of the following:

0 = Uninitialized
1 = Initialized
2 = Initial Sync
3 = Auto Recovery
4 = Normal
5 = In Error

As you can see on the above, the last one is wonky donkey!!! DFS BE BROKEN

So lets have a look through the events for dfs broken events:

and to double check with Powershell on the affected DC:

Get-WmiObject -Namespace 'root\MicrosoftDFS' -Class DfsrReplicatedFolderInfo

Nothing comes up, this is BAD!

So in the regisrty you should be able to check the recovery status

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters

So its stopped and not recovering.

The fix:

First get the guid of the C:\ drive:

MountVol

Now run this in a elevated command prompt:

wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="cc9a4e7a-0000-0000-0000-602200000000" call ResumeReplication

Wait 10 and check the replication status again:

and run the dsquery again:

HORRAY!!!!!  GPOs for everyone.

Handy bit of PowerShell my bestest ever friend wrote to check DNS accross domain controllers:

#do dns servers agree for dns
$results = $null
$results = @()
$DNSServers = Get-ADDomainController -Filter * 
$hostname = Read-Host('enter dns record to check')
foreach ($DNSServer in $DNSServers)
{
    $dnsrecord = Resolve-DnsName -Name $hostname -Server $DNSServer.HostName -Type A
    $result = New-Object psobject -Property @{
    dnsserver = $DNSServer.Name
    hostname = $dnsrecord.name
    IPAddress = $dnsrecord.ipaddress
    }
    $results += $result
}

$results | select hostname,ipaddress,dnsserver | sort ipaddress

Had a few people ask me recently why the attribute tab is missing for AD users in Active Directory Users and Computers.

First thing to check, is Advanced Features enabled:

Are you searching for the user??  If so then thats the issue, you CAN NOT get to the attribute tab from the search:

Go to the OU, open the user, booooom:

Hi All,

A chap called Michael Grafnetter has created a brilliant PowerShell script to check password hashes in Active Directory against a list of simple or common passwords.

This is great to encourage users not to use obvious passwords, for example if a company is called Contoso then you’d want to encourage users not to use Contoso1 etc.

Here’s how:

Download the software:

https://github.com/MichaelGrafnetter/DSInternals/releases/tag/v2.22

Copy the DSInternals directory to your PowerShell modules directory, e.g.

C:\Windows\system32\WindowsPowerShell\v1.0\Modules\DSInternals

C:\Users\John\Documents\WindowsPowerShell\Modules\DSInternals.

Launch Windows PowerShell.
(Optional) If you copied the module to a different directory than advised in step 4, you have to manually import it using the Import-Module .\DSInternals\DSInternals.psd1 command.

Next create a text file called passwords.txt and fill it with passwords you’d like to scan for, example:

Password
Password1
Contoso1

Then here’s an example script:

First set the password txt file.

Then set the Domain Contoller, in this case DC1

Then set the distinguished name of the OU and sub OUs you can to scan:

Note ” and ‘ are not showing up properly,

$dictionary = Get-Content passwords.txt | ConvertTo-NTHashDictionary Get-ADReplAccount -All -Server DC1 -NamingContext ‘dc=adatum,dc=com’ | Test-PasswordQuality -WeakPasswordHashes $dictionary -ShowPlainTextPasswords -IncludeDisabledAccounts

$dictionary = Get-Content passwords.txt | ConvertTo-NTHashDictionary
Get-ADReplAccount -All -Server DC1 -NamingContext 'dc=adatum,dc=com' |
Test-PasswordQuality -WeakPasswordHashes $dictionary -ShowPlainTextPasswords -IncludeDisabledAccounts

Active Directory Password Quality Report
----------------------------------------
 
Passwords of these accounts are stored using reversible encryption:
  April
  Brad
  Don
 
LM hashes of passwords of these accounts are present:
 
These accounts have no password set:
  Guest
  nolan
  test
 
Passwords of these accounts have been found in the dictionary:
  adam                Pa$$w0rd
  peter               July2016
 
Historical passwords of these accounts have been found in the dictionary:
  april               Pa$$w0rd
  brad                Pa$$w0rd
 
These groups of accounts have the same passwords:
  Group 1:
    Aidan
    John
  Group 2:
    Joe
    JoeAdmin
    JoeVPN
 
These computer accounts have default passwords:
  LON-CL2$
 
Kerberos AES keys are missing from these accounts:
  Julian
 
Kerberos pre-authentication is not required for these accounts:
  Holly
  Chad
 
Only DES encryption is allowed to be used with these accounts:
  Holly
  Jorgen
 
These administrative accounts are allowed to be delegated to a service:
  Administrator
  April
  krbtgt
 
Passwords of these accounts will never expire:
  Administrator
  Guest
 
These accounts are not required to have a password:
  Guest
  Magnus
  Maria

So today I was trying to running some cross domain PowerShell commands on Exchange but kept getting the following error:

The operation couldn't be performed because object 'user' couldn't be found on 'Server_Name.Domain'

Which basically means the Domain Controller your referencing can only see your sub domain and nothing higher.  So to resolve run this before the command:

Set-AdServerSettings -ViewEntireForest $True

So today I was working at a site that has a single Exchange 2010 server that forfills all the Exchange roles (I know….) which happened to fall on its ass.

First thing I did was check the Exchnage services which were in a state of “starting” which is never good and then I went to the registry and found:

MSExchange ADAccess, EventID 2141
Process STORE.EXE (PID=2996). Topology discovery failed, error 0x8007077f

MSExchange ADAccess, EventID 2142

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1760). Topology discovery failed, error 0x8007077f

Here’s a few screen shots:

As well as a few more related to AD.

After some investigation I found out that a new DC in a new site had been created for some DFS replication amongst other things.

As the system could start the Microsoft Exchange Active Directory Topology service (until it failed and is restarted by dependent services), Exchange’s other services were also triggered, leading to almost indefinitely restarting services as configured in their corresponding service recovery actions sections.

So next up is to look at Active Directory Sites and Services:

And as you can see from the screen shot the subnets are missing, which is going to cause issues as the new DC is on a different subnet.

When Exchange can’t determine in which site a computer belongs, the function DSGetSiteName, used to retrieve the current site, returns an error 1919 0x77f (ERROR_NO_SITENAME) which in turn kills off Exchange.  You can test this by running nltest /dsgetsite in a command prompt or by having a look at  HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName.

To solve the issue you can do any of the following:

1. Making the site association static using a registry key, which isn’t a best practice. If you must, set registry key HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SiteName(REG_SZ) to the desired site name;
2. Adding proper subnet definitions;
3. Remove the new site.

Finally give Exchange a  bounce and BOOM.

Note that the NetLogon service determines site association membership at startup and every 15 minutes. The Microsoft Exchange Discovery Topology service maintains this information by caching the information in the msExchServerSite attribute of the Exchange server object, in order to reduce load on active directory and DNS. Therefore, you might need to wait or restart Microsoft Exchange Discovery Topology if you want to renew site association membership.