Friday, August 22, 2014

Considerations for Deploying Active Directory Domain Controllers in Microsoft Azure

Azure is the new hotness. It seems like there are new features being lit up each week in the platform and it's gaining quite a bit of momentum. One thing that many organizations are starting to consider is extending their on-premises Active Directory Domain Services infrastructure out to Azure IaaS. Note that this is not the same as Azure Active Directory, which is an authentication solution for Office 365 and other cloud-based services.

One place where this is starting to gain momentum is with AD FS in support of Office 365. Organizations are starting to say "Hey, we've moved out messaging and collaboration to the cloud, why is our authentication infrastructure for those services still on-prem?" It's a fair question to ask, and I am starting to find that deploying AD FS in Azure in support of Office 365 is a great way for admins and engineers to get their feet wet in the platform.

This post is going to focus on deploying AD Domain Controllers to Azure. I may do a post on deploying AD FS to Azure as well, but step one is extending directory services to the cloud. The reason for this is twofold:
  1. There is no point to deploying AD FS in the Azure without DCs there as well. If the site-to-site VPN between Azure and your datacenter fails, authentication fails. This defeats the purpose of putting AD FS in Azure in the first place.
  2. Azure bills for egress network traffic. In very busy environments with thousands of authentication attempts per minute, this can add up to a pretty penny. Keeping all authentication "self-contained" in Azure will greatly reduce this cost.
Once you have provisioned your VNet, assigned address space to various subnets, and spun up your VMs, you need to do a few things to prepare for DC promotion.

Tuesday, May 27, 2014

GroupCalcPollingIntervalMilliseconds in SCSM 2012 Causes Queue Membership Issues

This TechNet article recommends changing the GroupCalcPollingIntervalMilliseconds registry entry to 1000000 to improve performance of System Center Service Manager. It is supposed to reduce the frequency with which Service Manager calculated group membership used within user roles to 10 minute intervals, which improves performance in large environments. There are three issues with this recommendation:

  1. 1000000 milliseconds is not 10 minutes, it's ~17 minutes. Minutes are not in base ten. If you want to set this key after reading the following bullet points, make sure you do your math correctly.
  2. This registry key impacts the application of SLOs to work items, as the GroupCalcPolling process is responsible for this.
  3. This registry key also impacts the process that relates a work item to a queue. If you're scoping what work items users can see by queue criteria, work items will only be added to queues within the specified interval.

This means that a user will not see work items scoped to them until the GroupCalcPolling process runs at the specified interval. By the same token, SLOs will not be applied until this interval elapses as well.

Obviously numbers 2 and 3 are an issue in all but the smallest environments, so use extreme caution when setting this key. It will improve performance, but it will impact other, potentially critical, areas within Service Manager that the SCSM team has apparently not documented.

Saturday, April 5, 2014

Managing Scheduled Tasks from Group Policy

There were two different questions on the front page of Server Fault today, both needing a way to deploy scheduled tasks to a large number of servers. The preferred method for this type of thing is to use System Center Orchestrator, but if you don't have System Center licensing, you can deploy scheduled tasks using GPO.

First, open the Group Policy Management Console. You can find the policy preferences that we care about in Computer Configuration > Control Panel Settings > Scheduled Tasks.

Right click on Scheduled Tasks and select "Scheduled Task (At Least Windows 7)" if you're targeting this at Window 7 or 2008 R2 or later.

You're now presented with the familiar Task Scheduler dialog. Here you can configure the task like you would on any individual computer.

You should now have a Scheduled Task item. The default action is "Update" but "Create" or "Replace" will have similar results. For a quick rundown of what the actions do, read this TechNet article.

If we hop over to one of the servers that this policy applies to and run a gpupdate /force, we can then go into Task Scheduler on the local computer and see the job that we defined in GPO.

Hopefully, this makes the deployment and management of scheduled tasks a bit easier if you don't have a proper workflow management system like System Center Orchestrator. Happy scheduling!

Thursday, March 27, 2014

LOPSA East 2014

As some of you may know, I will be speaking at LOPSA East in May.

I'll be doing a three hour session on Active Directory Domain Services during the Saturday morning block. You should all register and come hang out!

Saturday, February 15, 2014

On Asking for Help

I've noticed a disturbing trend on Server Fault lately. People are asking for help with things that they have not tried to find the answer to themselves. Some of the regulars on the site have speculated that it's concentrated within certain cultures. Others have said that it's from a younger inexperienced generation that want quick answers. I'm not sure if either of those are accurate, but it's got to stop for the long-term success of our profession.