DNS

Your DCs should be pointing to each other for DNS and your clients should be pointing to the DCs. If your clients are using other DNS servers, you’re going to have problems at some point. If you are, for some reason, required to use third-party DNS for external lookups, put those DNS servers in as Root Hints servers instead of pointing clients or DCs at them.

Just Say NO to top level policies

The Default Domain Policy should be your only top level GPO unless you have a really good reason to add more. In addition, the Default Domain Policy should be edited very sparingly. Why? Anything you link at the top level applies to EVERYTHING in your Domain. Do you really want all of your servers and Admin accounts locked down with the same policies you give to everyday workstations and standard user accounts? Decide on an organizational structure for your OUs where you can link your GPOs instead of linking them at the top level.

Group Policy doesn’t apply to Groups

Despite the name, you can’t apply Group Policy to a Group directly. GPOs can only apply to users and computers. If you need it to apply to a group of users or computers, you’ll need to remove Authenticated Users from the Security Filtering for the GPO and then put your group there to apply it to your subset of objects.

Getting a 5 minute hang at logon?

You’ve got a logon script problem. The default timeout for scripts is 5 minutes.

Group Policy Preferences not applying in XP (or other older OS’es)?

Is the CSE installed? Pre-Windows 7 OS’es will ignore Group Policy Preferences unless the Client Side Extensions are installed.

Enforced policies & block inheritance

If there are GPOs at a higher level that you don’t want to apply, you can use the Block Inheritance option on an OU to stop those GPO’s from applying. To combat this, a GPO can be set as Enforced so that it can’t be overridden at a lower level. If you can avoid both of these options, do so. They can cause major headaches.

Is something disabled?

This is something you’ll see in gpresult.exe output. When you right-click on a GPO, the Link Enabled option should be checked. If it isn’t, the icon next to the GPO will be lighter than other GPO’s. Also, make sure that the GPO Status in the Details tab of a GPO is set to Enabled.

Are you applying settings to the right OS version?

If you’re running a mixed environment of XP, Vista, and 7 like just about everyone, make sure that the policy that you’re trying to apply wasn’t intended to a different OS. When you’re editing a GPO, each option will have a “Supported on” area that tells you which operating systems are supported.

Group Policy – Supported Windows version

Permissions

This is also something that will show up in gpresult.exe (seeing a trend here?). By default, the Security Filtering for a new GPO is set to Authenticated Users; that’s everybody including Domain Users and Domain Computers. There’s no reason to change it unless you only want that GPO to apply to a subset of objects. You can put Deny’s in the Delegation, but I won’t usually recommend it.

File/share permissions

If you’re storing scripts outside of Sysvol, deploying software, mapping drives/printers, or using Folder Redirection, file and share permissions are your biggest enemies. Double, triple, and quadruple check them and they could still be wrong. If you’re having problems accessing a network resource, try connecting to it manually to see if you still can’t connect. The Event Log will also tell you if your user/computer can’t access the resource.

Precedence

Lowest linked GPO wins. If there is a top level policy set by a Domain Admin and 16 sub-OUs down there is a conflicting policy set by a departmental Admin, the lowest linked policy will win out unless the Enforced option has been checked. When in doubt, go to the OU in the GPMC and check the Group Policy Inheritance tab and you’ll be able to see the order they are processed.

Group Policy Precedence

Slow links

I’ve seen a few networks where the clients would detect that they were on slow links even if they weren’t. You’ll see in your gpresult.exe output if the client thinks it is on a slow link. If this is a continuing problem, you can disable slow link detection in Group Policy in Computer Config, Policies, Administrative Templates, System, Group Policy, Group Policy slow link detection, and set it to 0.

Loopback processing

No user polices? Check to see if Loopback processing is set to Replace.

Misplaced Objects

Is the user or computer where they’re supposed to be? I helped someone troubleshoot a problem for three days only to discover that the user account was in the wrong OU. Moved the user, refreshed the policy, problem resolved.

Apply policy to the correct object type

Make sure that you’re applying user polices to users and computer policies to computers. Separating your users and computers into separate OUs makes this easier to keep track of.

Folder Redirection oddities

Folder Redirection can do some weird things if you don’t watch out your settings. If you’re migrating to a new server name and moving all of the files yourself, make sure that you disable the option to move the users’ files to the new location. If not, you’re going to wind up with some angry users with missing files.

If the move option is disabled in Windows 7, the old folders will still be left behind even if a user logs in to the computer for the first time. You’ll either need to delete those folders or change the option to move the contents of the folder.

If you’re redirecting the My Documents folder, make sure that you mind the naming convention that the GPMC uses. If your file server is still using the old “My Documents,” the GPMC may try to change that to just “Documents.”

• Troubleshooting Group Policy – Part 5: Active Directory problems (0)
• Troubleshooting Group Policy – Part 4: Client problems (0)
• Troubleshooting Group Policy – Part 3: Group Policy not applied? (0)
• Troubleshooting Group Policy – Part 2: Test and deploy (1)
• Troubleshooting Group Policy – Part 1: User communication (0)

DNS

If you’ve gotten to the point where it looks like Active Directory (AD) is the problem, you’re most likely looking at some kind of replication issue. By far, the most common cause of AD replication problems (short of failed DCs) is DNS. Are you using AD integrated DNS? Are your DCs pointing to each other for DNS? Are the firewalls between each DC open on the correct ports?

Event Log

So the obvious place to look first is the Event Log. If you’re having replication problems, you’ll have errors in the Event Log, most likely a lot of them. Take a look here first for anything actionable.

GPOTool

GPOTool.exe is a handy utility that Microsoft puts into the Microsoft Product Support Reports suite of utilities. It is buried a bit, but after extracting the executable before installing the tools, GPOTool.exe can be found in your computer’s temp.

Running GPOTool.exe from one of your DCs without any switches will run through all of your GPOs and verify that your Group Policy Templates and Containers are synced and consistent across all of the DCs. You can also use the /gpo option if you just want to check one specific GPO.

GPOTool

Sysvol Replication

Are you still using FRS for Sysvol replication? Move to DFSR.

If you’re stuck on FRS, Microsoft has a great tool for troubleshooting FRS replication issues called Ultrasound.

If you’ve moved on to DFSR, you can run diagnostics by running the DFS Management snap-in, go to Replication, Domain System Volume, right-click and choose Create Diagnostic Report. Choose Health Report and you can stick mostly to the defaults. On the Options tab, make sure to change your Reference Member to the PDC Emulator (or the machine you typically connect to for editing Group Policy).

DFS Diag

As you can see, my one DC isn’t having replication problems (thank goodness!). If it was, you would get some nice errors or warning that you could use to track down the root cause of the problem.

DFS Diag Report

In the last post of this series I will cover a few common problems.

• Troubleshooting Group Policy – Part 6: Common problems (0)
• Troubleshooting Group Policy – Part 4: Client problems (0)
• Troubleshooting Group Policy – Part 3: Group Policy not applied? (0)
• Troubleshooting Group Policy – Part 2: Test and deploy (1)
• Troubleshooting Group Policy – Part 1: User communication (0)

When all else fails, reboot!

There are a few changes in Group Policy that require a reboot for the computer or a logoff/logon for the user. If you have clients that go long periods without rebooting or users that just lock their computers at the end of the day, this could be why some policies aren’t updating. If you’re deploying software to computers, using Folder Redirection, or have startup/shutdown scripts, you’ll need your computers to restart occasionally. The same goes for logon/logoff scripts, if you’re relying on scripts in your policy for changes, users will need to actually log out on occasion to get changes. If you can, time your policy changes that require a reboot with Patch Tuesday since the computers will, most likely, reboot to apply patches.

Wait… or run gpupdate

Group Policy refreshes every 90 minutes with a randomized offset of 30 minutes. If you change a policy right now, it could be as much as 2 hours before all of your clients get the policy. (Depending on how long Sysvol replication takes in your AD (or if you have a DC on the other side of a slow connection), it could possibly be longer.) If you made the change an hour ago and clients aren’t getting the setting, that’s completely normal. On the client, you can run gpupdate.exe to update changes that have been made to Group Policy. Running a gpupdate.exe /force will ignore any processing optimizations and reapply all of the Group Policy. Or, you can just keep on waiting until all of your computers complete their regular refresh.

gpupdate

Group Policy should refresh on its own without you having to manually run gpupdate.exe on every computer. Running the command manually is a great way for testing or to make sure a user/computer gets the change immediately, but shouldn’t be a necessity on every system. If gpupdate.exe hangs or generates an error, you may need to move on to the Event Log.

Gpresult

Gpresult.exe is a great invaluable tool for troubleshooting Group Policy that has been improved in Windows 7 and Windows Server 2008 R2. The output of gpresult.exe contains a wealth of information like what GPOs are applying to the computer/user, if the GPO was filtered, if the GPO is empty, whether or not the computer is on a slow link, security group memberships, OS version, site name, roaming and local profile locations, which DC the policy was retrieved from, and much more. Basically, gpresult.exe takes the RSoP data and turns it into something that a human being can actually read.

If you’re running the latest and greatest, you can run gpresult.exe /h nameofyourreport.html and get a pretty HTML report about what GPO’s are applying to the current user that looks just like the Setting tab in the GPMC. You may notice that the Computer area will be blank. Run the same command with an Elevated Command Prompt to see the Computer Area.

gpresult HTML output

If you don’t want pretty reports or want the output as text, you can run gpresult.exe with different options to get the output in text. The /r option will give you a pretty limited report that includes everything except the actual settings that are being applied. Personally, I like the verbose output with the /v option. By default, the output will be shown in the Command Prompt window. You can run gpresult.exe /v >> verbose_output.txt to save the output into a text file. If you want total information overload, /z provides “super-verbose” information.

gpresult verbose text output

Resultant Set of Policy (Logging)

Resultant Set of Policy (Logging) is available in the GPMC by right-clicking on a user or computer object, click All Tasks, and click Resultant Set of Policy (Logging). I personally prefer running gpresult.exe on the client side. RSoP Logging requires that the management station that you’re using have the ability to communicate with the remote computer which isn’t always available in every environment. Even if I don’t have physical access to or the ability to remote control the computer, I can have the end user email me the output of gpresult.exe for troubleshooting. I’ve even known people to stick a script on the computer that the user just has to click on to get the output without any pesky command line typing. RSoP Logging also gives the same output as RSoP planning, so it can be a little hard to look at. The output of gpresult.exe is much easier to look at and search.

Next steps

So now you know you have a problem and you have enough information to hopefully track it down. First, did the GPO apply? And, if it wasn’t, was it denied? You can get some of this in the Event Log, but it is usually easier to check your gpresult.exe output since both pieces of information should be there. If it didn’t apply or got denied, check the Event Log for more information about why the GPO didn’t apply or was denied. The potential number of possible possibilities you’ll see there are too great to discuss here, but you should get something good enough to search for online to resolve the problem. The typical causes are things like the Security Filtering, link not being enabled, GPO Status may have user or computer disabled, and issues with WMI filtering.

If the GPO did apply, but you’re missing settings, try a gpupdate.exe just to see if the client hasn’t refreshed. You’ll also want to refer to the gpresult.exe output here too. You may have a system on a slow link, a setting that isn’t applicable to the current OS, another setting taking precedence, loopback processing that is disabling the setting, or client side extension (usually Group Policy Preferences or third-party products) problems. If the output from gpresult.exe doesn’t tell you where the problem is, the Event Log should.

In the next post I will discuss Group Policy Active Directory problems.

• Troubleshooting Group Policy – Part 6: Common problems (0)
• Troubleshooting Group Policy – Part 5: Active Directory problems (0)
• Troubleshooting Group Policy – Part 3: Group Policy not applied? (0)
• Troubleshooting Group Policy – Part 2: Test and deploy (1)
• Troubleshooting Group Policy – Part 1: User communication (0)

So you’ve got computers or users with Group Policy problems. Where do you start? Troubleshooting any problem is usually a process of elimination. A lot of people want to run directly to the Event Log of the computer having the problem. Before jumping on the first computer where Group Policy is not applied, I suggest asking a few questions first so you can eliminate possible causes. A little detective work up front can make tracking down the actual problem much easier and may save you some time digging through logs.

Is this a local system or a remote (probably VPN-connected) system?

Some policies behave differently depending on whether a user/computer is connected directly to a LAN or remotely over a slower connection. For a remote user, the computer may have identified the connection as a slow link and may not be enforcing all settings properly. Additionally, some settings like Folder Redirection and scripts only run during a reboot and may require pre-logon VPN access to network resources like file servers or they won’t run. If the user is connected remotely, you may need to recommend that they connect to the VPN prior to logging into AD so their policy can process.

Were any changes made to Group Policy recently?

So this is probably the biggest no-brainer of all of the questions. If someone made a change, did the reported problem matched the change that was made? Was the change tested before it was rolled out to everyone?

Are there other cases where Group Policy is not applied?

If the issue is isolated to one person or one computer, you may be looking at an individual client issue. Do you have some users/computers getting the policy and others that aren’t? You may be looking at a clients that haven’t refreshed yet or a possibly even an AD issue.

If it is a subset, is there something unique about them?

Do any of the users/computer have anything in common that may relate to the problem they are having? Are all of the users/computers located at a specific AD Site? Are all of the computers running the same OS? Are all of the computers on the same subnet? Are they in the same building? Are all the users assigned to the same file server?

Does the user have Admin rights?

I haven’t seen it a lot, but a user with Admin rights can cause problems for Group Policy processing. Did the user change the assigned DNS servers? If you can’t get to the DCs, you can’t process Group Policy. Did the user go into the Registry Editor and make changes to any of the Registry keys related to Group Policy? Did the user make changes to the local firewall? Has the user installed any other kind of application that could be interfering with Group Policy?

Is the computer having hardware problems?

A bad stick of memory or a failing hard drive can play all sorts of tricks on a computer. I can’t say I’ve personally seen Group Policy processing issues because of hardware problems, but I have had someone try to blame a problem on Group Policy that ended up being a bad stick of memory.

Can you replicate the problem?

If someone else logs into the computer, do they have the same issue? If the user logs into another computer, does that person still have the same problem? If you drop a test user or test computer into the same OU and refresh the policy, are the Group Policy settings applied correctly?

Are there any outages known to IT?

This is another no brainer… If you’re having replication issues between your DCs that you or someone else is trying to resolve, it makes no sense to spend time troubleshooting Group Policy problems until the replication issues are resolved. If there are network issues that are disabling clients’ access to DCs, those network issues need to be resolved first.

Have IT infrastructure changes been made recently?

Was a file or print server replaced? Were any DCs upgraded or replaced recently? Has any network hardware like switches or firewalls been replaced/upgraded recently? All of these can potentially cause issues with Group Policy processing.

At this point, you are hopefully armed with enough information to help you track down the source of the problem if Group Policy settings were not applied. In my upcoming articles, I’ll discuss what you can do on the client and server side to track down and resolve your problem.

In my next post I will cover Group Policy problems that are related to client issues.

• Troubleshooting Group Policy – Part 6: Common problems (0)
• Troubleshooting Group Policy – Part 5: Active Directory problems (0)
• Troubleshooting Group Policy – Part 4: Client problems (0)
• Troubleshooting Group Policy – Part 2: Test and deploy (1)
• Troubleshooting Group Policy – Part 1: User communication (0)

I can’t stress enough how important it is to test out your new Group Policy settings before you start pushing them out to end users. How do you know they will work correctly in the real world if you haven’t tested them in a controlled lab setting first?

Creating a Group Policy test environment

In larger environments, IT departments may have a Test Active Directory Forest just for testing things like Group Policy. Unless you’re applying Group Policy to thousands or tens of thousands of computers, that may be overkill for your organization. Here’s what I typically do to test:

In my Active Directory (AD) organization, I like to keep a “Test” Organizational Unit (OU) that mimics a typical OU for a department. In that OU, I keep the same sub-OU layout, a few test user accounts, and test computers (usually virtual machines) where I can put any of my test Group Policy before I make it available to end users.

Within the Group Policy Management Console (GPMC), it is very easy to make copies of Group Policy Objects (GPOs) by going to the Group Policy Objects container in the Group Policy Management Console (GPMC), right-click on the GPO, choose Copy, and then right-click again, and choose Paste. I usually make a copy of the original GPO and include “TEST” in the name and link it inside of my Test OU. This gives me an OU where I can make changes to my policy without causing problems for existing users or computers.

GPMC with Test GPOs

Should I use physical computers for testing Group Policy or virtual machines? Personally, I prefer to test with VM’s. Why? If you mess up and lock down a computer to the point that it becomes unusable, you may have to re-image the computer. With a VM, you can rely on snapshots to go back in time without having to spend time or effort fixing the problem. Just be aware that if you decide to use Microsoft Virtual PC, the Undo Disks functionality is limited to rolling back to the last state of the VM. If you’re running Hyper-V, that is typically my choice for VM testing. If not, you can either spend the money for VMware Workstation or get VirtualBox for free.

Test real world scenarios

When you test your new policies, ensure that you’re also testing against computers and/or users that had the old policies applied and that have been in use by real people. In a lab setup, operating systems have this habit of having cleanly applied images that have never been used. User accounts and the files and settings that account have access to are pristine and haven’t been customized or changed. Some user policies can be affected by previous settings in the user’s profile. The biggest place where this happens is Folder Redirection. You’ll want to make sure that the settings that you’re changing take both new logons and existing logons into consideration. A good way to do this is to have some users that can test your changes when you’re almost ready to roll them out to everyone.

Stage changes

Depending on the change you’re making, you may not want to roll it out to every user or computer at the same time. For major changes, I usually like to drop a few user and/or computer objects into the Test OU and allow those objects to run for a few days. In addition to being a good way to test how the change works in the real world, it gives me the chance to see if anything is going to break or cause problems for end users before the change is rolled out to everyone. It is much easier to deal with a few unhappy customers that are having problems than a lot!

“Dog food” your Group Policy

As an IT department, I highly recommend “eating your own dog food.” From a Group Policy perspective, that means that you should have the same GPO’s applied to your day-to-day user account and computer that all of the other users in the organization are getting. It should also mean that new policies should get applied to you first. The quickest way to see how a Group Policy change will impact end users is to use it yourself every day. How do you know that a particular script makes logons slow if it doesn’t apply to you every day? How do you know that the screensaver timeout is too low unless you’re constantly having to log back in because you have the setting, too? How do you know that disabling certain settings hamper a user’s ability to work unless you have to deal with the same issue?

Resultant Set of Policy (Planning)

I’m mentioning the RSoP in Planning mode last because I personally have never gotten much usage out of it. In Active Directory Users and Computers, you can right-click on a User or Computer object, click All Tasks, and click Resultant Set of Policy (Planning) to see how policies will apply to users and computers. RSoP Planning will let you pick a user and computer and then select options like Site, slow network, Loopback mode, group memberships, and WMI filters to see what policies will be applied to a user and computer.

RSoP Planning Wizard

The problem? The output that you’re given makes it impossible to see the results of your policies. You’ll have to manually dig through everything. It is probably quicker to have a VM, drop it into your Test OU, and just test out the policies yourself to see if you’re getting the results you want. The gpresults.exe tool (which we’ll get to in a later article) gives much easier to read results.

RSoP Planning Results

In the next part of this series I will outline how you can identify a Group Policy problem.

• Troubleshooting Group Policy – Part 6: Common problems (0)
• Troubleshooting Group Policy – Part 5: Active Directory problems (0)
• Troubleshooting Group Policy – Part 4: Client problems (0)
• Troubleshooting Group Policy – Part 3: Group Policy not applied? (0)
• Troubleshooting Group Policy – Part 1: User communication (0)

Group Policy is a great tool that can make your life a lot easier as a systems administrator. But, what do you do when computers or users aren’t getting the correct policies? In this series, we’ll take a look at things you can do to prevent problems, common problems people have with Group Policy, and steps you can take to troubleshoot misbehaving Group Policy.

“An ounce of prevention is worth a pound of cure.” — Benjamin Franklin. Those words definitely ring true for deploying new Group Policy settings. There are a number of things you can do before deploying changes that may cost you some time up front, but will definitely save you time and grief down the road.

Know your customer

How well do you know the business processes of the group that will be getting your Group Policy changes? If you’re planning on implementing Group Policy for the first time or making significant changes, these changes can potentially have ramifications on the business operations of the group that will be receiving the policy.

Take screensaver settings for example. Turning on the screensaver and locking the computer after 15 minutes may be perfectly reasonable in an office setting, but could cause major problems on a warehouse or factory floor where employees need to constantly see something on a screen, but don’t necessarily interact with the keyboard or mouse. On the other hand, 15 minutes could be way too high for a computer in a public location like a reception or customer service desk where someone could potentially walk in off the street and start using a computer that has been idle for a few minutes.

Engage your customer and find out how their department operates. Do they have software they use that no other department uses that could be affected by what you do? Are there things their employees are doing on their computers that they want stopped like setting personal wallpapers? Are the settings that you’re planning to implement going to cause problems for their business operations? Asking a few questions up front can potentially prevent things from breaking because of the unforeseen consequences of changes.

Communicating changes

If you’re making a change that is going to be noticed by your customers, you may need to prepare them for that. I helped someone roll out a company logo wallpaper and screensaver to around a hundred computers over a weekend. The change had been requested by the owner of the company to standardize their computers. Unfortunately, the change wasn’t communicated to the employees. On Monday morning, things were crazy for the lone IT person. Numerous employees logged support requests and several even complained to the company owner about the change. Ultimately, the policy change was left in place; but, a quick email from the owner about the change before it was made would have eliminated a lot of confusion from the employees and support requests to IT.

Even if the change isn’t necessarily going to be noticed by the typical user, you still need to let someone know that a change is taking place. Most Group Policy changes are fairly silent when they occur; the average user probably won’t know that something has been changed even if they are having problems. Having a few insiders in the office that are aware of the change can be very helpful once end users start encountering problems and may give you the opportunity to tweak the policy before the problem spreads to other users.

In my next post I will give some tips of how to test Group Policy deployments.

• Troubleshooting Group Policy – Part 6: Common problems (0)
• Troubleshooting Group Policy – Part 5: Active Directory problems (0)
• Troubleshooting Group Policy – Part 4: Client problems (0)
• Troubleshooting Group Policy – Part 3: Group Policy not applied? (0)
• Troubleshooting Group Policy – Part 2: Test and deploy (1)

The traditional method for scoping Group Policy Objects (GPOs) in Windows Server 2008 Active Directory is to perform the following actions:

• Ensure that the GPO is linked to the appropriate Active Directory object (for instance, site, domain, OU)
• Use security filtering to ensure that the GPO affects only specified user and/or computer accounts

Security filtering a GPO

What many Windows systems administrators do not know (or may not want to know due to the learning curve involved) is that we can also use Windows Management Instrumentation (WMI) filtering to dynamically scope Group Policy.

WMI is extremely powerful in GPO application because we can target systems based upon hardware and software attributes such as CPU architecture, operating system, free disk space, BIOS version, and so forth.

It should be noted that because your WMI filters are parsed during every Group Policy refresh, WMI filters in GPOs are best reserved for time-limited scenarios to avoid undue performance impact on your domain controllers.

For instance, you may want to deploy a GPO with a WMI filter that scopes the policy for Windows 7 clients that have a particular hotfix applied in order to undo the installation. After your machines have ingested and processed the GPO, you can simply unlink the WMI filter or disable the GPO entirely.

Creating a WMI filter

To build your first WMI filter, fire up the Group Policy Management Console and expand your domain to expose the WMI Filters container. Next, right-click WMI Filters and select New from the shortcut menu.

Creating a New WMI Filter

In the New WMI Filter dialog box, add a name and (optionally) a description for your new WMI filter. Next, we can build the actual WMI Query Language (WML) query by clicking Add.

New WMI filter

WMI filters consist of two components: (a) the WMI namespace; and (b) the WQL query. The vast majority of Windows systems administration-related WMI classes are contained within the root\CIMv2 namespace.

If you have used the Structured Query Language (SQL) before, then you will be instantly comfortable with the basic syntax of the WQL language. If not, then you have a bit of a learning curve in front of you.

Please check out the following links for some useful assistance in writing WQL:

• WMI Filtering using GPMC
• Scriptomatic 2.0 Utility
• WMI Administrative Tools

In the following example screenshot, my WQL query targets domain systems that run Windows XP Professional.

A WQL query

Note that a single WMI filter can consist of more than one WQL query statement. Once you’ve saved your work, your new filter(s) will appear in the WMI Filters node in Group Policy Management Console.

NOTE: Active Directory replication ensures that both your WMI filters as well as your GPOs are available on all domain controllers.

Linking a WMI filter to a GPO

To link a WMI filter to a GPO using the GPMC, view the properties of the target GPO. Next, open the WMI Filtering drop-down list, which is now populated with any previously created WMI filters. Select the appropriate filter from the list—once you propagate the GPO to your domain, you are finished!

Linking a WMI filter to a GPO

You are probably familiar with the old carpenter’s aphorism “Measure twice, cut once.” This truism is especially relevant for us Windows systems administrators with respect to Group Policy application.

We are faced with the frightening question: How can we know in advance if our WMI filter works? Well, to that end I would like to point you to a nifty free utility by the GPO Guy called the WMI Filter Validation Utility.

The way this tool works is simple: we first have it analyze our GPO infrastructure and report metadata concerning any linked and unlinked WMI filters. This interface is shown in the next screen capture.

The WMI Filter Validator

We can then test a WMI filter by right-clicking its entry in the tool’s interface and selecting Validate from the shortcut menu. This launches a wizard whereby we can target a specific domain member computer.

Validating a WMI filter

We must remember that a WMI filter is essentially a Boolean True/False test in order for Active Directory to determine whether to apply a given GPO to a given computer. The WMI Filter Validation Utility works wonderfully to test this equation in advance.

WMI validation results

Conclusion

At this point you should have a solid idea as to what WMI filters are and how we can use them to dynamically scope our GPOs. You also know how to test WMI filter application prior to GPO deployment.

• Troubleshooting Group Policy – Part 6: Common problems (0)
• Troubleshooting Group Policy – Part 5: Active Directory problems (0)
• Troubleshooting Group Policy – Part 4: Client problems (0)
• Troubleshooting Group Policy – Part 3: Group Policy not applied? (0)
• Troubleshooting Group Policy – Part 2: Test and deploy (1)

The introduction of Group Policy Preferences into Group Policy seems to have quite a few people confused. I think that confusion has been compounded by all of the people who skipped Windows Vista, stayed with Windows XP, and are just now starting to implement Windows 7 on the desktop.

Group Policy Preferences

So what’s all the excitement about anyway? Assuming you’re one of those organizations that skipped Windows Vista, you’ve probably been living in the Windows XP Group Policy Management Console (GPMC) for a while. The first time you fire up the GPMC in Windows 7 and edit a Group Policy Object (GPO), you probably notice a new section under both Computer Configuration and User Configuration. In addition to Policies, you now have Preferences. What are these new “Preferences” and what do they have to do with Policies? First, let’s start by talking about Group Policy.

Group Policy introduction

Group Policy is a way for you to control most of the settings and configurations that exist for a computer or for any user that can log into the computer. Screensaver settings? There’s a Policy for that. Logon/logoff scripts? There’s a Policy for that too! Just about any setting or change you can make by hand can be made in a Group Policy. If you’re using Active Directory and are hand-configuring options for every computer and/or user that you support, or hand-mapping drive letters or printers, or even doing something simple like changing the wallpaper, you should seriously consider putting some of that effort toward learning how to use Group Policy so that your computers and users can be configured automatically.

Group Policy

Adding the computer to Active Directory gives you the ability to edit these Policies at the Domain level and assign them to computer and user objects in AD. So what do you need to do to start managing Group Policy for your Windows 7 and Windows 2008 R2 systems? Install the latest GPMC and start editing.

Group Policy Preferences

Group Policy Preferences was originally a product called PolicyMaker from Desktop Standard. Microsoft acquired Desktop Standard back in 2006 and, starting with Windows Server 2008, began integrating PolicyMaker into Windows. Windows Server 2008, Windows 7, and Windows Server 2008 R2 already have what they need to use Preferences out of the box. If you still have Windows XP, Vista, or Server 2003, the Client Side Extension (CSE) that will allow you to use Preferences is available as a download. Still running Windows 2000? Sorry, there’s no CSE download for Windows 2000.

Assuming you’re using AD, have the latest GPMC, and are running the latest Windows OS or have installed the CSE for the older version of Windows, here are some of the things you can do with Group Policy Preferences:

• Create and make changes to environment variables
• Copy files to the local file system
• Create/delete folders on the file system
• Make changes to .ini files
• Modify the Registry
• Create/modify/delete network shares
• Map network drives
• Create/modify/delete shortcuts
• Create ODBC entries
• Make changes to devices in the Device Manager
• Make changes to file associations
• Create and make changes to local user accounts
• Create and make changes to local groups
• Create VPN and dial-up connections
• Manage user application settings (requires plug-in written for the application)
• Modify power options
• Manage local printers
• Map network printers
• Manage scheduled tasks
• Manage services
• Manage Regional Options
• Make changes to Start Menu settings
• Make changes to some IE settings

Group Policy Preferences – Settings

Group Policy Preferences vs. logon scripts

If you’re experienced with Group Policy, you’re probably noticing that a lot of the options mentioned above are also available in the Policy area of a GPO or can be managed by logon scripts. One of the great things about Windows is there’s always more than one way to do something. If you or your IT shop’s expertise is in scripting, you don’t need to reinvent the wheel and start from scratch if you already have infrastructure that is working for you. But what if you don’t have all of those scripts already written? Preferences are a great way to accomplish the same goal without having to spend a lot of time or money learning something completely new.

Scripting isn’t something you can usually learn overnight. It’s a big hurdle for a lot of people. It’s also something that doesn’t usually have a standard. Ask three people to write a script to map a few drives based on group membership, fix permissions on a folder, and make a registry edit, and you’re probably going to end up with three wildly different scripts. Is that bad? Not necessarily, but if your scripts have a thousand lines of code (or more), you probably sweat every time someone makes an edit. One misplaced character or typo and the whole thing can stop working. And you do have every line of those scripts documented in the event that the person who wrote them is unavailable, right?

Preferences also follow the same refresh rules for Group Policy (every 90 minutes with a random offset of up to 30 minutes). With scripts, they only run at system startup/shutdown and user logon/logoff. Group Policy Preferences also have built-in logging to the Windows Event Log, another area where scripts can lag behind unless the scripts are very robust.

Group Policy Preferences vs. Group Policy settings

How do Group Policy Preferences compare to comparable Group Policy settings? The biggest difference between the two is enforcement. With a Policy, settings are enforced; in most cases, the user interface is either grayed out or gone completely so that the user can’t change the setting. With Preferences, the setting is applied once and can be changed later by the user. One caveat: if you’re using Replace a lot in your Preferences, your users are probably going to figure out that if they make a change to certain settings, those settings are going to change back in an hour or so when Policy refreshes for the computer.

Preferences also aren’t limited by the need for ADM or AMDX files. If you have an application that requires a license file to be copied to the computer, all you need to do is configure a Preference to copy the file. If you need to set an option that is stored in the Registry, such as the network name for a database server, you can browse the local Registry and create a Preference with the setting. Preferences don’t require your applications to have any awareness of Group Policy. As long as the configuration can be edited in the Registry, be made by copying a file over, you can use Preferences.

Group Policy Preferences gotchas

Policies are stored in a separate Policy area of the Registry. If you remove a setting in Policy, it will revert back to the original setting on the computer (or in the user’s account). With Preferences, the setting will stay unless you explicitly create a Preference that deletes it.

Mapping printers? Make sure you set the options for the Point and Print Restrictions for either the Computer (at Computer Configuration > Policies > Administrative Templates > Printers) or the User (at User Configuration > Policies > Administrative Templates > Control Panel > Printers). If you don’t, your printer mappings will fail if the computer is unable to copy print drivers to the local system.

Make sure the Client Side Extension for Group Policy Preferences is installed for XP, Vista, and 2003. If the CSE isn’t installed, those versions of Windows will completely ignore the settings in your Preferences when processing Group Policy.

Replace mode isn’t necessarily your friend. I’ve been burned by Replace mode several times. I can’t underscore enough that you should use Replace sparingly. Replace usually has the effect of running a Delete and then a Create. For example, if you map printers with the Replace option, Group Policy will delete the connection and reconnect to the printer. That may not sound like a big deal, but if your user wants that printer to be his/her default, you’ll have problems. Every time the Replace command runs, the user will lose that printer as the default if they have other printers on the system. I’ve also found that using Replace when you’re creating a local user account causes that user account’s SID to be regenerated.

If user options aren’t working correctly, you might need to check the “Run in logged-on user’s security context (user policy option).” Preferences run as the System account. Preferences that use network resources, such as mapping printers or network drives, need the user’s privileges to run properly. Checking this box ensures that the proper credentials are used.

Copying files? Check your network share permissions. If the local computer is getting the file, you’ll need to make sure that the Domain Computer has at least read access to the network share. The same is true if the user’s security context will be copying the file; make sure the user has at least read access.

Last, but not least, Microsoft maintains a list of currently available hotfixes for Group Policy. There is a section specifically for Preferences that may be of help if you’re having issues with a specific feature.

• Troubleshooting Group Policy – Part 6: Common problems (0)
• Troubleshooting Group Policy – Part 5: Active Directory problems (0)
• Troubleshooting Group Policy – Part 4: Client problems (0)
• Troubleshooting Group Policy – Part 3: Group Policy not applied? (0)
• Troubleshooting Group Policy – Part 2: Test and deploy (1)

MDT Workbench

MDT has two main sections within the Workbench: Information Center and Deployment Shares. Information Center contains links to documentation, online links (news), and components, where you download software. The other section is where you can create, populate, and manage deployment shares.

MDT 2012 workbench

The first task you do is right-click the Deployment Share node and create a new deployment share, using the Deployment Share Wizard. The path must exist already, but you can use a network UNC, local disk, or USB drive. Completing the wizard will share the path, create the following sub-directories, and copy files into tools, scripts, and control:

• $OEM$
• Applications
• Backup
• Boot
• Captures
• Control
• Operating Systems
• Out-of-Box Drivers
• Packages
• Scripts
• Tools
• USMT

Deployment Share Wizard

In the Workbench itself, you will see the following elements appear underneath your new deployment share:

• Applications for importing productivity software
• Operating Systems for each OS
• Out-of-box drivers to provide drivers not available in the native OS
• Packages updates and hotfixes
• Task-sequences where you create step-by-step rules to automate the build
• Advanced configuration where you can create a database with more granular rules

Applications, operating systems, packages, and out-of-box drivers are all empty and link directly to the directories of the same name. Task-sequences links to the control directory, which is where MDT keeps all the rules and configuration files for your deployment using XML files and two INI files called customsettings.ini and boot.ini.

If using a virtual machine for your build, you need to enable “file and printer sharing” on the host machine. You are now ready to build your OS deployment.

Building a deployment

The steps to build an OS deployment are simple and involve lots of right-clicking! The process is:

1. Right-click “Operating systems” and import your OS. It will import with a long name, so rename it to whatever you want.
2. Right-click “Task-sequences” and choose “standard client” in the wizard.
3. Edit the task-sequence to allow updates from both Windows update steps (under State Restore.
4. VirtualPC 2007 has a bug that reports the CPU speed as 2-4MHz. The default requirement is 800MHz, so the deployment will fail at the “Validate” step. To fix this, enter the minimum speed as 12 (MHz), and un-tick the check box. (See page 7 of the release notes). FYI: ZTIBIOS checks the BIOS against a BIOS blacklist, ztibioscheck.xml.
5. Right-click the deployment share and choose “Update Deployment Share” to generate the source.

The result is a bootable ISO in the boot directory of your share. Boot a new virtual machine with this ISO attached; it will connect to the share and run your task-sequence, as in the screenshot below:

MDT task sequence wizard

Note that deployment shares are entirely independent. This means you can create new shares for different departments, for example.

• MDT (Microsoft Deployment Toolkit) prerequisites and add-ons (0)
• Introduction to the Microsoft Deployment Toolkit (MDT) (0)
• Raffle: ManageEngine Desktop Central – Part 2: Features (2)
• Deployment toolkit Part 2: Driver deployment tools (0)
• Deployment toolkit – Part 1: OS deployment tools (2)

Before you even bother installing MDT, I suggest you install the MDT prerequisites listed in the following table, in order. For XP, you also need to install PowerShell.

MDT requirements

Note that you only need the WAIK supplement if you are deploying Windows 7 SP1 or Windows Server 2008 R2, SP1. Sadly, there is no install feature for it. You have to resort to the command line:

xcopy <source path> “C:\Program Files\Windows AIK\Tools\PETools” /ERDY

I recommend mounting the ISO or just extracting the files to avoid burning a DVD. If you installed the WAIK elsewhere, change the path.

Build content

Finally, there’s the build content to obtain and organize, which you will import into MDT. It’s best to do this first, according to the breakdown in the following table.

The MDT setup program installs a few shortcuts to the Windows Start Menu, but the main ones are the “Deployment Workbench” MMC snap-in and the help files. You only need the other programs for network deployment or for integrating into SCCM.

MDT add-ons

When you launch the MDT Workbench, it immediately presents you with a window containing a workflow and directs you to the components tab. This is where you download various add-on tools from within the MDT (albeit outdated versions). The following table describes these add-ons.

The WAIK will take a while to download, so if you haven’t already installed it, wait for it to download and install. Downloads save to “C:\Program Files\Microsoft Deployment Toolkit\Components\” in directories as appropriate.

In the next part of this MDT series I will discuss Windows deployment.

• MDT Workbench and Windows deployment (0)
• Introduction to the Microsoft Deployment Toolkit (MDT) (0)
• Raffle: ManageEngine Desktop Central – Part 2: Features (2)
• Deployment toolkit Part 2: Driver deployment tools (0)
• Deployment toolkit – Part 1: OS deployment tools (2)

I still remember the days (way back in 2003-2004) when we were asked to change the local administrator password manually on all 2000+ computers in a weekend. Back then, system administrators in my region were pretty far removed from automation. But things evolved greatly after that, and system administrators started using programming languages (like VBScript) to automate tasks. Automation tasks have become much easier these days with the introduction of PowerShell.

So, let us see how we can change the local administrator password for a given list of computers using a PowerShell script.

Changing the administrator password with PowerShell

$password = Read-Host "Enter the password" -AsSecureString
$confirmpassword = Read-Host "Confirm the password" -AsSecureString
$pwd1_text = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($password))
$pwd2_text = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($confirmpassword))
if($pwd1_text -ne $pwd2_text) {
    Write-Error "Entered passwords are not same. Script is exiting"
    exit
}

As you will notice in the above code, I am prompting to confirm the password twice so that it won’t be entered wrong and cause the script to run again. I am also reading the password in a secure manner so that no one else can see it when it is being typed. Once the password is confirmed, the next two lines of dotnet code convert the password into plain text for comparison. If the comparison fails, the script exits; otherwise, it continues.

Now that we have the password, it is time to read the list of computers from a text file.

Reading list of computers

if(!(Test-Path $InputFile)) {
    Write-Error "File ($InputFile) not found. Script is exiting"
    exit
}

$Computers = Get-Content -Path $InputFile

Before reading the text file, I am doing a small check to see if that file exists or not. If the file is not found, the script exits. Otherwise, the script reads the contents of the file using the Get-Content cmdlet and stores the list in an array called $computers.

Now that we have the list of computers, we can start changing the password for each computer. That is what the below code does.

Chaging the password on multiple computers

foreach ($Computer in $Computers) {
    $Computer    =    $Computer.toupper()
    $Isonline    =    "OFFLINE"
    $Status        =    "SUCCESS"
    Write-Verbose "Working on $Computer"
    if((Test-Connection -ComputerName $Computer -count 1 -ErrorAction 0)) {
        $Isonline = "ONLINE"
        Write-Verbose "`t$Computer is Online"
    } else { Write-Verbose "`t$Computer is OFFLINE" }

    $obj | Select ComputerName, IsOnline, PasswordChangeStatus
   
    if($Status -eq "FAILED" -or $Isonline -eq "OFFLINE") {
        $stream.writeline("$Computer `t $isonline `t $status")
    }
           
}

I am looping through each computer account in the array and first checking if it is online or not by using the Test-Connection cmdlet. This cmdlet does a ping check by sending one ICMP packet to the computer. If the ping is successful, the script changes the password. To do that, I am using the WinNT interface, which is pretty famous from VBScript days. After I get the reference to the administrator account, I invoke a method called SetPassword to change the password. If the password change fails, the respective error will be recorded using the catch block.

That’s it. The script has done its job and you will see the result in the console.

As you’ll notice in the output, the script creates a list of computers where the password has failed. The file "failed-computers.txt" is stored in the directory where the script picked up the computers list. If you want to provide a different directory where you want to store files, just pass the directory name to the -OutputDirectory parameter while executing the script.

Download the complete script from here.

A few tips for using this script

Type “Get-Help .\Update-LocalAdministratorPassword.ps1 -Detailed” in a PowerShell console for help.

• Use the -Verbose switch from the command line if you want to see the debug information and error messages at each stage.
• Passing the file name to the script is optional. The script will prompt you for the file if you don’t pass it.
• Using this script, you can change the password of any local account. Just replace “administrator” with the account name for which you want to change the password.

• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• PowerShell tutorial for admins – Part 6: Managing server roles and features (0)
• PowerShell tutorial for admins – Part 5: Using PowerShell Scriptomatic (0)
• PowerShell tutorial for admins – Part 4: Obtaining server metadata (1)

As a Windows systems administrator, you may be required to document the contents of your server racks. The reasons for this documentation are myriad and manifold:

• Compliance with industry/governmental regulations
• Compliance with organizational IT policy
• Theft protection/insurance reimbursement
• Accountability to stakeholders
• General industry best practice

Microsoft Visio 2010 is a part of the Microsoft Office System suite that is optimized for the visualization of all business processes. Visio is especially well-suited to our work in IT.

Background information

First of all, it should be said that unlike many core members of the Office System suite, Visio 2010 is a Windows-only application.

NOTE: Mac OS X users tend to get a lot of mileage from Omnigraffle for their business process visualization needs.

Second, only two of the three Visio 2010 stock keeping units (SKUs) include the rack diagram template. Thus, if you are a systems administrator you will want to avoid Visio Standard 2010 and instead purchase a license for Visio Professional 2010 or Visio Premium 2010.

• Visio 2010 Edition Comparison
• Visio 2010 Retail Pricing

Third, you need to know that Microsoft Visio 2010 includes vendor-neutral shapes in its built-in stencil set. Thus, if you need or want to model real-world gear, you will need to obtain original equipment manufacturer (OEM)-provided Visio stencils.

The good news is that these are amazingly easy to come by. Most IT hardware vendors are overjoyed to provide you with detailed Visio shapes that model their equipment. Most of these shapes have associated shape data such that you can track details regarding each element in your infrastructure.

• Cisco Stencils
• Network Equipment Shapes for Microsoft Visio
• Visio Café
• NetZoom Visio Stencils
• Visio Guy Visio Links
• Router Freak Visio Stencil Files
• Lync Server 2010 Visio Stencil
• Exchange 2010 Visio Stencil
• HP Visio Stencils

Building the Visio diagram

Open Visio 2010, and from the default Backstage view, select the Network template category, and then the Rack Diagram template.

The rack diagram Visio 2010 template

Once you have the template loaded, you can bring out the Rack shape from the Quick Shapes or Rack-mounted Equipment stencils. The default size of the rack is 42 rack units (Us); however, you can resize the rack to adjust for your preferred dimension.

Next, you can load up your custom third-party stencils by clicking More Shapes > Open Stencil from the Shapes window. Browse to your downloaded .vss file, and away you go!

Loading an external stencil

Next, select a shape from a stencil and drag it into the rack. Look at the next screenshot: do you see the little red squares? This denotes a glue to connection point operation. In Visio shape connection points are denoted by blue Xs; when you glue a shape to a connection point, this effectively links the shapes together.

Gluing shapes in Visio 2010

Finally, navigate to the Data ribbon tab and select Shape Data Window. You can now attach metadata to each network shape in the diagram. Visio 2010 gives us tremendous flexibility in storing and reporting on shape metadata.

For that matter, the subject of pipelining in external data into a Visio 2010 diagram warrants one or more blog posts on its own. Let me know in the comments portion of this post if you’d like a tutorial on this subject.

The finished product

Conclusion

Admittedly, we only scratched the surface in terms of what Visio 2010 is capable of doing with respect to visualizing your IT infrastructure. As I mentioned earlier, I am more than happy to walk you through more advanced operations; let me know what you think.

• FREE: DriverView – View drivers (0)
• FREE: Speccy – System information for Windows (0)
• FREE: NovaBench – Free benchmark software (1)
• FREE: Memtest86+ – Memory test software (4)
• FREE: Memtest86 – A memory diagnostic tool (5)

As you probably already know, the Kerberos authentication protocol has limited tolerance for time skew between client and server. Specifically, the time difference between domain computers needs to be less than five minutes.

Some Windows administrators want to synchronize their Windows Server 2008 system clocks to an external atomic time source. How can we accomplish this goal? Well, read on!

The Windows Time Service: Basic operation

The Windows Time (W32Time) service exists in both Windows Server 2008 R2 as well as Windows 7, and is the “engine” that drives system time synchronization within an Active Directory domain.

By default, the domain controller that holds the PDC Emulator FSMO role is the authoritative time source for the domain. More broadly, the PDC Emulator in the forest root domain holds the authoritative time for the entire forest. Check out the following Visio diagram:

Default time sync behavior in Active Directory

In the above diagram, the forest root PDC Emulator (A) serves time for the entire forest. Other domain controllers within the domain (B) synchronize their time with the PDC Emulator. In turn, domain member servers (D) and domain workstations (E) synchronize their time with any available domain controller. PDC Emulators and domain controllers from other domains (C) synchronize their clocks with either forest root domain controllers or the forest root PDC Emulator.

NOTE: You can ascertain the domain controller that holds the PDC Emulator role by opening an administrative command prompt on any domain controller and issuing the command dsquery server –hasfsmo pdc.

All of the previously described behavior happens “out of the box,” with no special configuration required on the part of the Windows systems administrator. A bit of complexity comes in when we want our authoritative server to synchronize its system clock with an external time source. Let’s do that now.

Configuring the authoritative time server for the domain

Pointing our domain authoritative time server (the PDC Emulator role holder, recall) at an external time source requires some tinkering with the Windows Registry. To this end, you might want to create a Registry backup before proceeding with this work.

All of the following value changes are stored in the following Registry root path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time

First, we must change the server type to NTP by modifying the Type value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type. Change the value data to NTP. This setting reflects use of the Network Time Protocol, an industry standard protocol for time synchronization and management.

Second, we need to set the proper NTP announce flag. Change the AnnounceFlags value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags to 5.

Third, we will enable NTPServer. To do this we must change the value data of the Enabled value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\ TimeProviders\NtpServer to 1.

Fourth, we need to specify our external time sources. To do this, we modify the NtpServer value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters.

This is where things get a little hairy. Windows expects a space-delimited list of DNS host names with the hexadecimal value 0×1 appended to each one (don’t even ask).

You can obtain a list of candidate atomic clock servers by visiting the NTP Pool Project Web site. The following screen shot shows my own value data:

Configuring external time sources

Fifth, we’ll set the NTP polling interval by modifying the SpecialPollInterval value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\ NtpClient\SpecialPollInterval. The recommended value here (reference from Microsoft) is 900 Decimal.

Sixth and finally, we need to configure time correction settings. Start by modifying the MaxPosPhaseCorrection value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\ Config\MaxPosPhaseCorrection; set the value data to a “reasonable” decimal value such as 1800 or 3600 seconds.

You’ll also want to set the corresponding MaxPosPhaseCorrection value to the same value you used for positive time phase correction.

Quit the Registry Editor, open an administrative command prompt, and submit the following command in order to bounce the Windows Time service:

net stop w32time && net start w32time

Pointing domain devices to a time server

As I mentioned earlier, as long as your domain member servers and workstations are legitimate domain members and have the Windows Time service running, they will automatically synchronize their clocks with a domain controller.

You can always verify from where a particular Windows box is synchronizing its time by using the “Swiss Army Knife” w32tm command-line tool.

As you can see in the below screen shot, the statement w32tm /monitor gives you the core information at a glance:

Monitoring NTP in Windows 7

The screenshot also references UDP port 123; this is the well-known port that belongs to the Network Time Protocol. Please be sure to allow traffic on UDP 123 in your domain so that you do not inadvertently block NTP communications between your servers and client devices.

Finally, you should now (if you don’t already) that we can fully customize the NTP client behavior by using Group Policy. From the Group Policy Editor, navigate to \Computer Configuration\Administrative Templates\System\Windows Time Service\Time Providers.

As you can see in the following screenshot, you can edit the Configure Windows NTP Client policy to tweak (and enforce) any and all NTP client settings.

NTP client customization via Group Policy

Conclusion

Whew! We certainly covered a lot of ground in this tutorial. I wish that Microsoft made it easier to manage the Windows Time service, don’t you? Please feel free to leave your questions and observations in the comments portion of this post.

• Microsoft Exam 70-640 – Active Directory trusts (0)
• Microsoft Exam 70-640 – Active Directory Forests and Domains – Sample question (5)
• Microsoft Exam 70-640 – Active Directory Forests and Domains (0)
• How to disable USB drive use in an Active Directory domain (0)
• Managed Service Accounts and Read-Only Domain Controllers (RODC) (0)

While constantly checking Task Manager and Resource Manager, I would sometimes notice high CPU utilization due to what I call the 3-headed monster. Here’s the definition for that:

3-headed monster

The user experience of Windows Indexing, System Restore, and/or Windows Error Reporting causing less than desirable states of desktop responsiveness especially during logon process. These are three Windows “features” I would consider disabling to improve performance immediately following logon. Disabling these will also improve overall performance.

Indexing

Let’s start with indexing. The theory of indexing is sound and I think can be applicable to home desktop users. However; on workstations in the business environment, I’m not so sure.

I’ve seen indexing cause slow performance when the Users directory is included in indexing. If you read my previous post, you learned how to reduce the size of the user’s roaming profile. That is helpful for the profile synchronization process but doesn’t reduce the size of the local profile. This local profile can be very large and could contain a very large number of files. I’ve found that removing this directory from indexing can greatly improve performance.

Here’s how to disable it.

From the Control Panel search for Indexing. Click Change how Windows searches. The Indexing Options dialog box will display showing you the number of items indexed. Click Modify to disable Indexed Locations.

Indexing Options and Indexed Locations

System Restore

Now on to System Restore. This is another feature that I feel has a better place in the home environment. It allows you to recover easily should something go wrong. But again, I have seen this cause massive system lagging when it’s running. I recommend disabling it and here’s why. Most shops have at least one spare machine lying around. Keep that as a hot spare and replace that machine that took a nose dive into the concrete-filled swimming pool. Roaming profiles and server data storage mean that in this case that machine is just a dumb terminal anyways. Turn off the extra services in favor of performance for your users and they’ll be much happier.

Here’s how to disable it.

Right-click Computer and select Properties. Click Advanced system settings and then the System Protection tab. Select a drive and then click Configure. Select radio option to Turn off system protection.

Disable System Restore

Windows Error Reporting

Just a quick disclaimer, I’m a big fan of Microsoft. They’re aren’t perfect but they sell good products that are universally recognized by anyone. In fact, I think they’re so great that I’m willing to bet they don’t really need every one of my workstations reporting every little problem. As with System Restore, I’m interested in removing anything that is going to cause lagginness (if that’s a word) for my end user.

Very rarely, I’ve seen the WER directory grow very large. Disabling indexing on the Users directory should mean that a large WER directory isn’t too big of a deal. The location of the WER directory is typically C:\Users\%username%\AppData\Local\Microsoft\Windows\WER.

Here’s how to disable it.

Windows Error Reporting can be disabled using group policy. If you want to disable by computer, create a GPO and configure Computer Configuration\Administrative Templates\System\Internet Communication Management\Internet Communication settings. To disable by user, customize the GPO section User Configuration\Administrative Templates\System\Internet Communication Management\Internet Communication settings.

Turn off Windows Error Reporting

In both the computer and user settings, there are also several other communication settings that I would highly recommend you review and consider disabling.

For additional information please refer to this TechNet article.

A couple other reminders that I may be helpful: Make sure that anti-virus and anti-malware are set to scan at times when user’s are not active. Also make sure that server backup activity is not affecting user performance.

Also read 10.5 ways how to speed up a slow Windows

• Troubleshoot slow logon – Part 1: Profile size (0)
• How to disable the Shutdown Event Tracker in Windows Server 2008 R2 (0)
• FREE: Smart Defrag – A defragmentation tool (9)
• FREE: NovaBench – Free benchmark software (1)
• Turn off indexing in Windows 7 and Windows Vista? (5)

In a previous article, you learned how to connect to Windows-based Server Message Block (SMB) shares from Mac OS X. Here we turn the tables and discover how we can share file resources in Mac OS X Snow Leopard with Windows-based client computers.

If you are like me, then you are accustomed to the enterprise-class file sharing and access control that are afforded to us in Windows. This being said, you are likely to find the Mac OS X file sharing options to be rather limited.

Setting up a Mac for Windows Sharing

From your Mac OS X Snow Leopard desktop, open the Apple menu and select System Preferences.

Opening System Preferences

In the System Preferences panel, in the Internet & Wireless icon group, open the Sharing item.

Mac OS X Preferences pane

In the Sharing preference pane, enable File Sharing.

NOTE: In previous versions of Mac OS X, the relevant option was named Windows Sharing.

When you enable File Sharing, you simultaneously enable the Samba server service. Next, click Options (shown as “A” in the next screenshot).

Sharing pane

Select the option Share files and folders using SMB (Windows), and then check any local Mac OS X accounts that you want to enable for sharing. What this option does is to allow you to populate your shared folders’ access control lists (ACLs), explained further on in this article.

Enabling SMB server on Mac OS X

Click the plus sign (+) beneath the Shared Folders list (marked “B” in Figure 3) and browse to your desired directory. When you’ve located that directory, select it and then click Add.

Browsing for a folder to share

You will now see the name of that selected folder in the Shared Folders list. Next, click the plus sign below the Users: field (marked “C” in Figure 3) and select the Mac OS X user account(s) that you want to add to the ACL.

The New Person button allows you to create a special type of Mac OS X user account known as a Sharing-Only account. You should protect these accounts with (of course) a strong password.

The main difference between Sharing Only accounts and standard Mac OS X user accounts is that Sharing Only accounts cannot be used to log on interactively to a Mac OS X computer. Therefore, using these identities is a good idea from a security standpoint.

Enabling sharing for Mac users

The specific access options for shared folders in Mac OS X is either quite straightforward or needlessly basic, depending upon your perspective. Your choices are: Read & Write, Read Only, and Write Only (Drop Box).

The default permissions for a given folder are inherited from the folder’s underlying UNIX directory permissions.

Share access control options

The following exhibit shows the completed configuration for our shared folder named script.

The script folder is now shared

One more thing before we switch over to Windows: to make the Mac’s discoverability by Windows-based clients as transparent as possible, we will want to set a NetBIOS workgroup name for the Mac.

To do this, re-open System Preferences and open the Network item. Select your Ethernet connection and then click Advanced.

Network preference pane

From the Ethernet configuration dialog, navigate to the WINS tab and set both a NetBIOS name as well as a workgroup name. For discoverability in Active Directory domains, just add the NetBIOS “short name” of the domain (for instance, 4Sysopslab.com would be 4SYSOPSLAB, as shown in the following figure).

Configuring the Mac for workgroup membership

Making a client connection from Windows

I trust that you are familiar with the myriad methods by which we can establish an SMB-based client connection to a file server:

• The Map Network Drive command in Windows Explorer
• Universal Naming Convention (UNC) path from the Run box
• The net use command
• Network Control Panel item

The following exhibit demonstrates the process of mapping a Windows drive letter to a Mac-based SMB share by using the archaic net use command.

Connecting to Mac OS X share from Windows

In observing the previous exhibit, the question probably arose in your mind, “What about authentication? What is going on here, exactly?” Well, the reason why I was able to run the above net use command without specifying Mac credentials is because I allowed access to the Everyone special identity. This identity works the same way in Mac OS X as it does in Windows—the same security precautions apply regarding its use, too.

If you want to make an authenticated connection to a Mac share by specifying credentials, then we should map a network drive using Windows Explorer.

Mapping a network drive in Windows

In the Map Network Drive dialog box, type the UNC path to the Mac share, and be sure to enable the Connect using different credentials option. Next, click Finish.

Configuring a mapped drive

You are now prompted for your “workgroup” credentials. Type in your desired Mac OS X account creds and then click OK.

Providing Mac OS X credentials

If all goes well, then the new mapped volume will appear in Windows Explorer:

Connection to Mac from Windows Explorer

Conclusion

At this point you might be thinking, “Wow, I’m disappointed. I thought that Mac OS X had more enterprise-level networking built into it.” Well, as it happens, it really does. In future installments of this series I will show you how we can link Open Directory, the Mac’s enterprise LDAP directory service, with Microsoft’s Active Directory Domain Services. At that point we really get closer to “big time” leveraging of Mac OS X in business.

• Troubleshooting the “Network accounts are unavailable” error in Mac OS X Lion (2)
• Active Directory login scripts in Mac OS X – Part 3: Third-party alternatives (0)
• Active Directory login scripts in Mac OS X – Part 2: Using Open Directory (0)
• Active Directory login scripts in Mac OS X – Part 1: Basic Approaches (1)
• Connecting to Windows shares from Mac OS X (11)

I recently spent some time troubleshooting slow logons. I had several complaints and had also personally witnessed some very slow logons. After some investigation, I found that nearly all of the user’s had either a very large profile or had directories with extremely high file count. Rather than just delete and hope the problem didn’t happen again, I decided to seek out a solution that would prevent this from happening in the future.

As you may know, just before discovering a solution, there’s usually a key discovery that lowers your blood pressure and allows your confidence level to return to normal. For me, that moment was discovering the power of using the Exclude directories in roaming profile and Limit Profile size Group Policy settings together.

Exclude directories in roaming profile and limit profile size

The Group Policy Object (GPO) setting Exclude directories in roaming profile is one of those settings that is unusually self explanatory. It allows you to create a list of directories, from the root of the user roaming profile location, that should be excluded from roaming profile synchronization.

How do I configure it?

This group policy setting is located in the User Configuration/Policies/Administrative Templates/System/User Profiles section of a GPO. To add multiple folders, separate them in the list using a semi-colon. For example, to exclude the Cookies directory and the Mozilla directory use this for your value:

AppData\Roaming\Microsoft\Windows\Cookies;AppData\Roaming\Mozilla

Exclude directories in roaming profile

What to exclude

Sometimes profiles grow large and you may not be sure which directories are the cause. This is where the Limit Profile size setting comes in very handy. Enabling the setting allows you to specify what the Max profile size should be as well as the message to use to notify the end user. This could be a double-edged sword. It can prompt your user to contact you when their profile is large but should be used with caution depending upon your user group. In my experience, I found this was a great way to target those experiencing slow logons due to profile size.

For the admin, the real power in this setting is the Profile Storage Space dialog box that is enabled in the system tray of the user’s desktop. It allows you to quickly view a list of the files in the profile sorted by size. I found this to be invaluable. That is because the cause of each user’s large profile can be unique.

Profile Storage Space dialog box enabled with Limit profile size

In your environment, I would recommend enabling this setting with a large Maximum profile size of somewhere around 300MB for those user’s that you know are having problems with slow logon. This will allow you to begin to assess the cause of the large profiles. As you add directories to the Exclude directories in roaming profile setting, you will see directories disappear from the Profile Storage Space view.

• Modify Exclude directories in roaming profile GPO setting that applies to the user
• Synchronize domain controllers
• Refresh group policy by running gpupdate /force from the command line
• Log the user off and then back on
• Double click the Profile Storage Space icon in the system tray

Ideally, you want to get profile size below 50MB. Below is the list I’ve compiled that has taken care of this issue for most of my users. This should work for Windows Vista and later desktop users. AppData\Roaming\Microsoft\Windows\PrivacIE;AppData\Roaming\Microsoft\Windows\Cookies; AppData\Roaming\Mozilla;AppData\Roaming\Adobe;AppData\Roaming\Macromedia;$Recycle.Bin; AppData\Local;AppData\LocalLow

In the next article, I’ll discuss how customizing the three-headed monster (Indexing, System Restore, and Windows Error Reporting) can improve user logon and desktop performance for domain users.

• Troubleshoot slow logon – Part 2: The 3-headed monster (0)
• How to disable the Shutdown Event Tracker in Windows Server 2008 R2 (0)
• FREE: Smart Defrag – A defragmentation tool (9)
• FREE: UserProfilesView – View user profiles (0)
• FREE: NovaBench – Free benchmark software (1)

Universal Serial Bus (USB) flash drives are undeniably convenient and easy to use. However, these devices pose very real security threats.

Number one, allowing your users to mount their own USB flash drives provides a vector for malicious code into your network. Number two, a malicious user can steal sensitive data by copying it to their flash drive and leaving the campus.

Here are a couple excellent articles that delve more deeply into IT security threats posed by USB devices:

• Social Engineering, the USB Way
• USB Drives Pose Insider Threat

You may decide to institute an IT security policy in your domain that prohibits use of personal USB devices. This is all well and good, but how many of your users will actually adhere to the policy without some kind of a control in place?

Fortunately, Windows Server 2008 R2 provides us administrators with a method for easily disabling USB drive access on Active Directory domain assets. Let’s get to work.

Defining the restriction

One important thing to keep in mind is that Microsoft made it MUCH easier to control removable drive access in Windows 7/Windows Server 2008 R2 Group Policy. If you need to restrict USB drives on earlier client operating systems (including Windows Vista), then one of the following links should prove helpful to you:

• How can I prevent users from using USB removable disks (USB flash drives) by using Group Policy (GPO)?
• Group Policy..Block USB
• HOWTO: Use Group Policy to disable USB, CD-ROM, Floppy Disk and LS-120 drivers
• Step-by-Step Guide to Controlling Device Installation Using Group Policy

Now then: from one of your Active Directory Domain Services domain controllers or from an administrative workstation, open the Group Policy Management Console and link a new GPO to the appropriate target (domain, OU, etc.).

Within the Group Policy Editor, navigate to \Computer Configuration\Policies\Administrative Templates\System\Removable Storage Access.

NOTE: If you prefer to set these restrictions on a per-user basis instead of computer-wide, then use the Group Policy path \User Configuration\Policies\Administrative Templates\System\Removable Storage Access.

Group Policy – Removable Storage Access

Note from the above screenshot that we can use Group Policy to limit access to the following device classes:

• Optical drives (CD and DVD)
• Floppy drives
• Removable disks (USB devices)
• Tape drives
• Custom device classes

By far, the most restrictive restriction (pardon the redundancy) is the policy All Removable Storage Classes: Deny All Access. If we enable this policy, as is shown in the following screen capture, then we prevent affected users from mounting ANY class of removable media.

All Removable Storage classes – Deny all access

Naturally, we want to apply GPO security filtering to ensure that only our desired users and computers are affected by our new policy. From the Group Policy Management Console we can make use of the Security Filtering and/or the WMI Filtering areas to properly scope our GPO. This is depicted in the following screen image:

Disable USB drive

In order to put your new GPO into effect immediately, open an administrative command prompt and issue the following command:

gpupdate/ force

This command refreshes Group Policy throughout your Active Directory domain.

How the restriction works

Once your GPO has been ingested by your domain, a user will see the following message box whenever they attempt to mount a restricted media device:

Disabled removable drive

It’s as simple as that!

Conclusion

In this article you learned how to leverage Windows Server 2008 Group Policy to disable USB drive us in our Active Directory domain. Have you initiated this policy in your environment? Please feel free to share your experiences and questions in the comments portion of this post.

• Microsoft Exam 70-640 – Active Directory trusts (0)
• Microsoft Exam 70-640 – Active Directory Forests and Domains – Sample question (5)
• Microsoft Exam 70-640 – Active Directory Forests and Domains (0)
• FREE: PhoneFactor – Mobile phone based two-factor authentication (1)
• How to synchronize Windows Server 2008 with an external time server (6)

In my previous article, we defined services and service accounts and also examined what options there are for selecting a service account for use with a particular service or application.

Here we take that fundamental knowledge and put it in more of a practical context. In real world multi-tier Web application scenarios, a Windows administrator can quickly become overwhelmed in keeping track of which service account he or she used with which application or service.

Consider the following example diagram:

A typical multi-tier Web application topology

Think of how many service accounts we require in the preceding scenario:

• Client services (likely if the client is using anything beyond a simple Web browser to access the Web application)
• IIS services
• AD and related infrastructure services (DNS, DHCP, etc.)
• Application services (SharePoint 2010, for instance, requires an entire suite of service account-attached services and applications
• SQL Server services
• “Standard” Windows services (Server service, etc.)

What is a busy Windows systems administrator to do? Well, read on and I’ll tell you.

Tip #1: Remember the Principle of Least Service

The IT security principle of least service means, in a nutshell, if you don’t absolutely require a specific service, disable it. Just turn it off. By performing this action we not only conserve system and possibly network resources, but we also reduce the number of attack vectors a malicious user can employ to penetrate your network.

As you know, we can manage all aspects of Windows services by using either the Service Control Manager (services.msc) MMC console or (even better) through Group Policy. The relevant Group Policy path is \Computer Configuration\Preferences\Control Panel Settings\Services.

Managing services with Group Policy

Tip #2: Know exactly what your applications and services are doing

Microsoft does a fairly decent job of enumerating the system privileges and file system permissions that its enterprise applications grant automatically to service accounts. For instance, check out the following links and prepare to be surprised:

• SharePoint 2010 Account Permissions and Security Settings
• SQL Server 2008 R2: Setting Up Windows Service Accounts
• Exchange 2010: Roles, Rights, and Permissions

You need to remain ever-aware of any “out of the box” privilege escalation that your line-of-business applications grant to service account. The best way to do this is to keep a wary and scrupulous eye on the vendor’s documentation.

Tip #3: Be Vigilant regarding the Everyone and Authenticated users groups

Everyone and Authenticated Users are dynamic security principals, which means that their membership is controlled by your network environment itself and that we administrators cannot control membership to these group identities.

The Everyone identity includes all authenticated and unauthenticated network users (this includes Local Service, people).

The Authenticated Users identity includes all domain user and computer accounts who have successfully authenticated to Active Directory. This group includes the Local System and Network Service built-in service account identities.

Thus, our “take-home” message is to keep a careful eye on where and how we are assigning access permissions to these two special groups.

We can control which accounts have which system privilege by using Group Policy; the relevant Group Policy path is \Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment.

Managing user rights with Group Policy

NOTE 1: System privileges are also called user rights. Either way, we refer to system-wide abilities such as logging on as a service, logging on locally, changing the system time, and so forth.

NOTE 2: Be sure to exercise due diligence and perform research prior to making user rights assignments in Group Policy. We don’t want to inadvertently break LOB application access.

Tip #4: Remember that network service authenticates as the Computer

If you opt to associate the built-in Network Service service account to a network-aware service, be aware that when that service makes a remote connection, it does so under the security context of the “calling” computer account (not user account).

Thus, you may need to adjust the discretionary access control lists (DACLs) on relevant target systems to include an access control entry (ACE) for the calling computer.

Editing a DACL for an IIS Web application

Tip #5: Use separate domain user accounts for services and applications

The main reasons why I suggest that you use dedicated domain user accounts for service accounts instead of the built-in identities are as follows:

• By using domain user accounts as service account logons, you can more granularly audit access locally and across your network
• For applications that support them, managed user accounts (MSAs) enable you to use domain password policy with your service accounts
• A domain user account has unquestioned visibility throughout your entire domain and Active Directory forest
• Domain user accounts can be more definitively targeted with Group Policy
• Using domain user accounts consistently makes it easier to manage multi-tier application infrastructures

Speaking of Group Policy, you might want to ensure that your domain service accounts are denied the Log on Locally user right at the very least. This action will prevent a malicious user from succeeding in an interactive logon attempt by using a breached service account.

With regard to my final point about consistent use of service accounts, Microsoft recommends that you assign different service accounts to different services within each enterprise application. The thinking here is that an attacker would have to compromise more than one account to “own” your application.

The only “gotcha” with using multiple service accounts is the pure confusion factor that can happen if you deploy the service accounts with no consistency. To reduce the confusion, (a) store your service accounts in separate organizational units (OUs) in Active Directory; and (b) name the accounts in an intuitive manner.

Conclusion

In this lesson we learned some industry best practices for using service accounts in a Windows-based, multi-tier application infrastructure. To be sure, we have truly only scratched the surface of this behemoth of a topic.

Please feel free to share your own experiences, war stories, tips, etc. in the comments portion of this post. The Windows admin community deeply needs a vibrant yet solid knowledge base for this subject.

Further reading

• Service Accounts Step-by-Step Guide
• Services and Service Accounts Security Planning Guide

• FREE: PhoneFactor – Mobile phone based two-factor authentication (1)
• How to disable USB drive use in an Active Directory domain (0)
• Service Account best practices Part 1: Choosing a Service Account (0)
• Four fast ways to improve security in SQL Server 2008 R2 (12)
• Managed Service Accounts in Windows Server 2008 R2 (7)

It is a common mistake for entry-level Windows systems administrators to associate a local or domain Administrator account with Windows services and applications. I hope that you can see how dangerous a practice this is. If a malicious user were to compromise a service account, then that malicious user accesses your domain up to and including all level of privilege of the associated service account.

It is my goal in this mini-series on Windows service accounts to teach you exactly what these accounts are, what options we have in using them, and what specific best practices Microsoft recommends for their use. Let’s get to work.

What is a Service?

A service is compiled code that is typically long-running and executes with no user interaction. By “long-running” we mean that many services are configured to start automatically with Windows. By “no user interaction” we mean that the service typically runs in the background with no visible front-end user interface.

As you know, we can view and modify services by using the Service Control Manager (services.msc) MMC console. We can also view active services by using Task Manager or Sysinternals Process Explorer.

NOTE: Process Explorer is a far superior choice for viewing live processes because we can “drill into” the svchost.exe generic host processes to see individual service names.

Viewing services in Sysinternals Process Explorer

The IT security principle of least service means, simply, that if we don’t need a particular service on a system, we should disable said service. Note that I said disable the service and not simply set its startup type to Manual.

By applying the least service principle, we not only conserve system resources but we also minimize the attack surface of the system.

What is a Service Account?

A service account is a Windows user identity that is associated with a service executable for the purpose of providing a security context for that service.

More broadly, we can say that service accounts are used not only for Windows services, but also for many enterprise applications. For instance, SharePoint 2010 requires service accounts not only for its registered Windows services, but also for its internal application components.

Microsoft introduced managed service accounts (MSAs) in Windows Server 2008 R2 as a way to ease our administrative burden in managing service account passwords. The great thing about MSAs is that we don’t have to worry about our domain password policy messing up our service accounts and breaking our line-of-business (LOB) applications.

The bad thing about MSAs is that because they are still so new, their use is not supported universally, even among Microsoft’s own enterprise application portfolio.

NOTE: Surprisingly, MSAs are supported in SharePoint 2010 but not in SQL Server 2008, which is the data store used by SharePoint.

Because of this compatibility problem, we will not include the use of MSAs in this discussion of service account best practices.

Options for Service Accounts

In terms of selecting a user account for a service or application, our choices fall along two lines:

• A built-in operating system identity
• A local or domain user account

The following table summarizes the major aspects of the built-in OS identities that are used as default service accounts in Windows.

I would like to point out some additional facts concerning the account identities in the previously given table:

You don’t have to manage their passwords. Because these built-in identities are created by Windows itself, the operating system manages their account passwords. In this respect these accounts function like MSAs.

The System account is very highly privileged. The Local System identity is granted system privileges that make this account in many ways more powerful than the built-in Administrator account. Although Local System was designed for access on a local computer only, this account can be associated with services and applications that move across your network. In this case, the credential that is presented to remote processes is Domainname\machinename$.

Be wary of Local Service and Network Service account group membership. Again, the ‘Local’ and ‘Network’ parts of these account names inform us that the Local Service and Network Service accounts are targeted at local and network use, respectively.

However, you should always keep in mind that the Local Service account runs locally as a member of the computer’s Local Users group (Domain Users on domain controllers) and runs remotely as an anonymous connection.

By contrast, the Network Service account runs locally as a member of the local Users or Domain Users groups, and runs remotely as a member of the Authenticated Users group. In addition, Network Service inherits any permissions that have been granted to the source computer account in Active Directory.

User Accounts as Service Accounts

You can sidestep some of the complexities of running services with the built-in service accounts by instead using a local or domain user account. One “gotcha” to keep in mind is that Windows automatically grants additional privileges (most notable the Log on as a Service user right) to user accounts we associate with services.

Service account privilege escalation

In addition, applications that leverage service accounts may grant additional permissions on top of the OS system privileges.

For this reason, it is imperative that you never use a service account for interactive logon. In other words, a human being should never log on to a system by using a service account identity.

We can again use the wonderful Sysinternals Process Explorer tool to retrieve “at a glance” data concerning specifically which system privileges have been granted a service account-driven process.

Sysinternals Process Explorer – System privileges service account

So Which Account Should I Choose?

According to Microsoft, Windows administrators should choose service accounts based upon the following hierarchy. This hierarchy is ordered from least privilege to greatest privilege:

1. Local Service
2. Network Service
3. Unique domain user account
4. Local System
5. Local Administrator account
6. Domain Administrator account

Obviously, options 5 and 6 in the list represent “worst-case scenarios” in which a given service or application simply will not run with a service account containing lesser privilege and permissions.

Conclusion

In this lesson we learned the basic terminology governing service accounts in Windows. We also examined the options available to us in service account use. In the next installment of this series, we will cover the practical application of service accounts in a multi-tier network application context.

• Service Account best practices – Part 2: Least Privilege implementation (0)
• Raffle: VisualCron – An advanced task scheduler for Windows (0)
• AutoAdministrator 2.3 – Part 3: Remote execute: Programs, services, shutdown/reboot (0)
• Prevent restarts triggered by third-party applications (1)
• Four ways to stop a shutdown or reboot (7)

What’s better than being able to check on server health status through the Nagios monitoring views? Having Nagios notify you of server health status automatically! If you have ever had a server fail, shut down, or hang—only to learn about it later from disgruntled users—you’ll understand why this feature is so valuable.

Creating and Managing Contacts

Nagios can notify you of certain changes or issues in server configuration that may occur. Sometimes you want different alerts sent to different email addresses. For example, you may want to send alerts about a database server’s health to the DBA, and send all other alerts to the systems administrator. To define a single contact, navigate to your ICW root and go to folder /etc/nagios/nagwin. Open the contacts.cfg file in your favorite text editor. Let’s get started on defining contacts. A contact definition has the following form:

define contact {   
contact_name           systems_admin_1; short name of contact
usegeneric-contact     default contact template
alias                  Johnny Bernard Doe; full name
email                  jdoe@mycompany.com; email address
}

The “use” directive informs Nagios of which contact you would like to use. For now, use the default generic-contact option; we will explore contact templates in a bit.

Once you create several contacts, you may want to group them together, like you would with an email alias. Suppose we have four contacts: two admins and two DBAs. We might want to create two contact groups: sysadmins and dbadmins.

define contactgroup {    
contactgroup_name sysadmins;                 system alias
alias Systems Administrators;                full name of alias
members systems_admin_1,systems_admin_2;     comma separated list
}
define contactgroup {
contactgroup_name                            dbadmins;
alias                                        Database Administrators;
members                                      dba_1,dba_2;
}

Configuring Notifications

Nagios allows the administrator to configure notifications at different levels of granularity, including, but not limited to:

• Who is being notified
• Type of notification event (host status vs. service)
• How severe the event is (from service flapping to host downtime)
• When the event occurs

Notification options are defined in the templates.cfg file using host, service, and contact template directives. You can find an exhaustive list of directives with explanations here, but let’s start out by exploring some simplistic templates and directives.

Contact Templates

Contact templates allow us to define shared notification attributes for different contacts. Some contact template directives include:

• service_notification_period: When the contact can receive service notifications
• host_notification_period: When the contact can receive host notifications
• service_notification_options: What kinds of service notifications the contact receives
• host_notification_options: What kinds of host notifications the contact receives
• service_notification_commands: How service notifications are handled
• host_notification_commands: How host notifications are handled

We can put together an “admin” contact that receives only host notifications on a 24×7 basis and for all types of notification events:

define contact {    
name                             generic-admin-contact;
service_notifications_enabled    0; don’t enable service notes    
host_notifications_enabled       1;    
host_notification_options        d,u,r,f,s; all   
host_notification_commands       notify-host-by-email; send email
register                         0; because this is a template
}

Note that we can also define these options on a “per contact” basis; the only difference is that these directives would be specified in the contacts.cfg definition for that contact rather than in the templates.cfg contact template definition.

Host Templates

Host templates enable administrators to define some shared notification options for different host templates. Consider the default Windows Server template. By now, most of the directives should be fairly self-evident because they are so similar to the contact template directives:

define host {
name                   windows-server; alias
use                    generic-host; base template definition
check_period           24 x 7;
check_interval         5;
retry_interval         1;
max_check_attempts     10;
check_command          heck-host-alive; typically use this notification_period
notification_interval  30;
notification_options   d,3;
contact_groups         admins;
hostgroups             windows-servers;
icon_image             win40.png
register               0; because it’s a template
}

Imagine we wanted to create a Windows DB server template that had all of the attributes of the Windows Server template, with two exceptions: you want notifications to be pushed to only those in the dbadmins group, and you want to change the notification options to include all states. You would add the following definition:

define host {
name                   db-windows-server; new name
use                    windows-server; base template
notification_options   d,r,u,f,s; new options
contact_groups         dbadmins; new group to notify
}

Service Templates

Service templates allow you to configure how services will be handled with regard to notifications. We will not be covering these directives in the interest of your time, but they are explained in several other guides online.

End Result

Once you have configured your contacts, contact groups, and notification templates to your liking, restart the Nagwin_Nagios service in services.msc. Upon restart, your configuration will kick in. You can verify any contacts you’ve created in the Configuration -> Contacts section of the Nagios web administration interface.

• Poll: Are you currently using a monitoring solution? (11)
• SCOM 2012 review – Part 8: Dashboards (0)
• SCOM 2012 review – Part 7: Linux and JEE monitoring (4)
• SCOM 2012 review – Part 6: Application Performance Monitoring (APM) (1)
• SCOM 2012 review – Part 5: Network Monitoring (0)