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 Schedul...

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 ...

Active Directory (AD) is one of the more flexible products provided by Microsoft. While they have spreadsheets and white papers for how many users should be in each on-prem Exchange database or how you should structure your site collections in SCCM, guidance on AD design is kind of sparse. My assumption is because directory designs are so environment-specific as to be resistant to generic instructions. This flexibility means two things: You can tailor the configuration and security of a domain to precisely and efficiently match the requirements of the environment it's there to support, making maintenance easy and allowing for future expansion.   You can screw things up really, really badly and not even know it. You see, the assumption in AD overall is you know what you're doing. There are very few warnings, no popup to let you know you just granted Bob in Accounting the keys to the kingdom or an easy wizard that lets you review your configurations before deploying them to ...

In my company, my overall department often takes over environments for business units who have built their own, then found they lack the time/knowledge to manage it effectively. It then falls upon my team to reorganize the Active Directory domain to follow industry/internal security standards and best practices. This article covers one of the most common low-level offenses we encounter: shared service accounts. Like so many questionable decisions, using a shared service account seems like such a good idea on the surface. You only have to create one account in AD, you only have to record and track one set of credentials, app installers only have to remember one set of credentials, permissions for different processes will likely overlap (meaning you only have to grant the access once), etc. However, I have a personal story that will help highlight why you're playing with fire. Let's travel back to early 2008. It was the first week of my current job, and I was trying to learn ...

Summary Most Active Directory object types have hundreds, if not thousands, of attributes. It's obviously not reasonable to put them all in the GUI, and even though Microsoft did everyone a favor by introducing the Attribute Editor tab in Server 2008, that doesn't help those looking to manage access to those attributes in the Advanced Security section. Yes, the security assignment can be done via PowerShell, but I often encounter users who aren't familiar with its syntax/output, and a screenshot showing checkboxes is far more useful than trying to explain a block of PowerShell text. There are ways to display attributes via Active Directory Users and Computers (ADUC) by modifying the schema, but customizing the schema is bad (mmkay?), and we're more concerned with displaying these attributes in the Advanced Security list than on reporting the values in them. Thankfully, we can accomplish this on a per-client basis without affecting the directory itself: the dssec.dat...

Summary A significant portion of being a good systems administrator is knowing how to accomplish tasks without doing more than is required. Maybe the best example of this is granting access to resources in Active Directory. When a user or team needs access to something in the directory, the beginner/bad sysadmin will take the easy way out, probably by using a default role like Account Operators or granting full control over the OU where the resources reside. After a while, you'll start seeing users in places where only groups should be or realize you've given someone the ability to reset the passwords on your elevated or production service accounts when you only wanted them to be able to unlock standard users. I'm not overstating things when I say the ACLs below are the basis for my entire directory design. AD's ability to grant permissions on a per-attribute level is what makes things like the separation of resources, the deployment of a proper role-based security ...

Summary Several things suck about Microsoft's DNS implentation, but the top two for me have to be security and backups. I don't know how many times I've had to explain to a team that I was not going to give them access to the DNS MMC snap-in because it would mean dozens or hundreds of Deny ACLs on zones in that environment. But that's another post. This post is about DNS backups. After experiencing the kind of event that causes one to review one's DNS backup plan, I found there wasn't a tidy way to back up AD-integrated zones like the options for AD, DHCP, and other infrastructure services. I started with a 36-line .bat file that required modification and an individual scheduled task for each zone that needed to be backed up. With the advent of the basic DNS cmdlets in Server 2008 R2, I moved on to an unholy combination of a PowerShell script that gathered zone info and called my old script in a loop. Not efficient, but it only needed one scheduled task. ...

If you're in IT, you've been there: something is broken/not working, and you've exhausted both your knowledge and your internal documentation (if you have any). So you start searching, scouring the web for any clue that might make some part of the puzzle fall in place or at least change the error code. Over my 15+ years in the industry, I've found personal blogs to be the most useful resources in these situations, mostly because they're written by peers who have no style guidelines or forced biases toward/against certain companies or technologies. I've benefited enough from these kind people that I feel I need to start giving back. Everything I write here will have roots in an actual issue/build I've experienced, so I hope it will eventually become a useful repository. So the goal of this blog is to help people, either by aiding to fix a problem or giving them knowledge that will help them avoid problems. It should go without saying, but I feel like I ha...