Wednesday, October 28, 2015

Windows Administration is Easy. Anyone can do it.

This is something that Windows administrators hear a lot, especially from *nix or storage folks. There's a stigma surrounding Windows and it is reflected in both compensation and respect in a lot of organizations. Open up Dice or Indeed and see how many six-figure Windows jobs you can find - now do the same for storage or Linux administration. There are certainly top-tier Windows gigs available, but they are much fewer in number than the others. I think that this disparity is caused by a few different factors:

You can do a lot through the Windows GUI
The most common knock on Windows is that everything is point-and-click. This is, of course, not true, especially in the era of PowerShell, but the myth persists. In many cases the GUI in Linux is limited and most Linux servers are installed without a GUI anyway. This forces Linux administrators to be intimately familiar with their command-line interface, which eases them into scripting. Linux admins have been laughing at us for years in this department - they had bash, dash, zsh, tcsh and we had cmd.exe. They had every right to gloat about this....until PowerShell was released.

Everyone knows Windows
Growing up in the 80s and 90s, almost everyone is heavily exposed to Windows on the desktop, whether it's in school, at home, for gaming, etc. Many IT professionals considered themselves as "power users" before they got into IT. Unfortunately, the ability to overclock a GPU or install StarDock doesn't translate into useful skills for an IT pro.

Microsoft didn't play the cross-platform game until recently
This absolutely isn't the case today. With many components of the .NET stack being open sourced, Linux on Azure and Hyper-V being a first class citizen, and much of System Center and other management tools supporting OS X, Linux, and Unix IT pros have a much larger set of options than they did in the past. If you go back 5 or more years, the cross platform story was not a compelling one, so many organizations that didn't want to be locked into a platform looked at OSS over Windows. This lead to a number of Linux/Unix folks feeling that Windows simply wasn't suitable to run their business on.

The reality couldn't be farther from the points above. When you're talking hybrid cloud with System Center, Hyper-V, Azure, and PowerShell, there's an amazing end-to-end platform that simply doesn't exist elsewhere. For the tiny two person dev startups, this might not be a compelling idea, but for the enterprise that's struggling to understand how and where cloud fits for them, it's critical. When you're looking at ExpressRoute, Azure Pack/Azure Stack, PowerShell DSC, and System Center there's a lot to like.

So, if you're a Windows admin, don't take any crap from the Linux guys at work. Microsoft loves Linux! Skill up on Azure, learn automation, and venture into the brave new cloud world that we are living in.

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!