Symptoms Out of nowhere, domain members start throwing errors about their trust relationship with the domain not working. You could also be receiving general logon errors by interactive users and service accounts. The behavior will likely be limited to one AD site, but will occur on seemingly random servers within that site. Resolution Check the drives where the NTDS database exists on all domain controllers in that domain. If any have filled up, expand them or clean them off, then reboot the affected servers. If you cannot log into the servers via console or RDP, try to force a shutdown through the hypervisor or chassis (if applicable). As a last resort, do a manual power-down via button or power cable, then boot up. See the Notes section for more details of this specific incident. Cause Normally, when a Windows machine does a domain authentication/authorization check, quite a few things happen in the background. One of those things is finding a working domain controller

Symptoms This can manifest in many different ways. Here are some of the most common: Support personnel report they can't unlock or reset the password for a user even though the target user's account is in the same OU as many other accounts that are behaving normally. Support personnel report they can't change the membership of a group even though the target group is in the same OU as many other groups that are behaving normally. Support personnel report they can't modify an attribute for a user even though the target user's account is in the same OU as many other accounts that are behaving normally. The primary identifying characteristic of the situation described here is the resetting of the security of whatever object they're trying to modify. IE, you may be able to grant support personnel rights to modify it, and it will work, but the next time they go back to do the same, the permissions are missing again. To confirm the underlying issue is the on

Symptoms Synchronization tasks within Azure AD are not kicking off at all. No errors are present in the application/system logs. In fact, nothing is in the application logs. Resolution Make sure all the appropriate ADSynchScheduler properties are set correctly. Open Microsoft Azure Active Directory Module for Windows PowerShell .   Run the following command: Get-ADSyncScheduler The result should be something like this: AllowedSyncCycleInterval : 00:30:00 CurrentlyEffectiveSyncCycleInterval : 00:30:00 CustomizedSyncCycleInterval : NextSyncCyclePolicyType : Delta NextSyncCycleStartTimeInUTC : 12/15/2017 5:19:45 PM PurgeRunHistoryInterval : 7.00:00:00 SyncCycleEnabled : True MaintenanceEnabled : True StagingModeEnabled : False SchedulerSuspended : False SyncCycleInProgress : False Make sure SyncCycleEnabled is set to True and SchedulerSu

This is part of my ongoing AD Design series. Check here for primer on the intent. As mentioned in my last post, I'm going to assume a certain level of knowledge about Active Directory is held by the readers of this series. One of those assumptions is you can navigate the wizards necessary to promote a couple domain controllers and get a base domain up and running. Again, if that's outside of your abilities, there are many, many guides for that online. For this post, I'm going to assume you're starting with a brand new domain. It may seem elementary, but two of the most important things to consider in AD design are: How your configurations will affect existing systems within the domain.  How your configurations will affect future efforts within the environment. How long you've been managing domains and your knowledge of how your systems integrate with your domain will determine how well you're able to guess at those (and make no mistake, you are