binaryfactory.ca

Depending on how you use Active Directory in your organization, you may be setting a lot of security policies on workstations, and some of these settings can be problematic during the automated build of computers.

A few workarounds exist to avoid applying those to the workstations being imaged:

* Create a temporary OU for the computer account, and move it to the proper location once the build is done
* Change the order of the steps in your build to avoid issues caused by security settings
* Configure a GPO to override the settings that need to be set only during deployment, and filter that only to machines being used.

For multiple different reasons, I had to use the last option. It is a rather clean option, as it doesn’t involve moving computer accounts after the build or any chances on the domain during the imaging process, other than joining the machine, which is great.

One word of notice: Make sure whatever you are overriding is not a must for security and is simply an “annoyance”, because eventually (within a few minutes probably), a user WILL figure out how you’re doing the filtering and WILL apply it to his own machine, in order to bypass some security settings.

Only a few steps are involved :

1) Create a GPO that will set the values to what they need to be during the build (don’t link it yet)

2) Create a WMI filter called “BoxBeingBuilt” or something similar. Have it do a query on something you know is true only during imaging. If you can’t find anything reliable, do something like this:

Select * from Win32_Environment Where Name = “BuildinDaBox”

3) Ensure your built process sets a system variable with that name at the beginning, and removes it at the end.

Tada!

Having issues pushing SCOM through the Windows firewall?

You opened the Remote Administration exception, you can ping it, you can browse shares, file and print sharing is enabled, yet it still fails?

There is one thing I have not seen documented in the SCOM installation/deployment guides: The agent actually adds an exception for itself when it runs, so if you block local exceptions (What’s the point of having a GPO for the firewall config on your serves if you don’t?) , it will fail.

Add this to your Firewall policy, as a program exception:
%SystemRoot%\422C3AB1-32E0-4411-BF66-A84FEEFCC8E2\MOMAgentInstaller.exe

Be sure to open it for the proper IPs only for added security. Then try to push it again..

Good luck!

Having issues similar to:

Trying to enable EFS on a specific OU, while it’s disable at the top of the structure or domain?
Recovery certificates from two different GPOs mixing up instead of being replaced?

Overall EFS GPOs looking like they aren’t merging properly?

Well, it’s not because EFS GPOs are supposed to behave like black magic. Turns out there’s a bug, Microsoft’s aware of it, but doesn’t think it would be a good idea to FIX IT on Windows XP and 2003.

Thankfully, all it means is you need to edit your GPOs from a Vista, 2008 or Windows 7 machine.

KB : EFS may not be enabled expectedly after you disable a policy and this policy turn off the EFS feature

Opening my EFS GPOs in Windows 7, switching the Allow/Don’t allow and applying the ‘change’ fixed my GPOs. A few minutes later, and stuff was behaving like it should’ve been… Can I have those wasted hours of my life back, Mr. Ballmer?

Today I read a post on Windows Networking by Brien M. Posey about “The Confusion of AD Design”.

He argues that some people use way too many OUs and that “less is more”.

As I said before, there are situations that do warrant using multiple OUs. This is particularly true in situations in which there are multiple administrators, and each administrator needs to be delegated control over a different portion of the network.

Well, I’m not aware of many domains that do not have “multiple administrators that need to be delegated control over a different portion of the network”. Those that don’t have that usually don’t have any OUs created other than the default ones, with every user under Users, and every computer under Computers. Of course there might be some exception, for example a domain used only to host your Exchange servers, however, most companies that pay high priced consultants to come in and set up their Active Directories have structures a little more complex than a 25 employee small business.

Having a lot of OUs can be very useful in almost any big domain structure. Let’s say you have 50 different types of servers. Each of these server sets has their own Hardening rules. You apply a “master” hardening GPO at the top of your OU structure, that locks everything down, and then you unlock things for each application, at the OU level. This way, your OUs apply in the proper order by default, and delegation is pretty easy as each application has their own container.

At least, at the end of the article, he acknowledges this:

Right about now, you might be wondering what I really have against creating multiple OUs. There are a couple of reasons why I do not like using multiple OUs unless I have to. Maybe it’s just laziness on my part, but the first reason why I like to try to stick to using a single OU in an Active Directory design is because having multiple OUs tends to complicate LDAP queries.

Well, just do a subtree search then! Laziness, on my end, makes me want to have a structured design where Group Filtering is the exception rather than the rule.

When working a lot with Group Policy, one thing that I would love being able to do is merging user right assignments. If you’re aware of how to do it, be sure to post a comment (Workaround, 3rd party tool, etc).

Let’s say you have 500 servers. All servers run some agent service that must always be set to automatic, and for which you have customized ACLs. (You grant helpdesk the right to restart the service for example).

Well, this is pretty easy to handle as every service can be handled in different GPOs, so you just create a GPO with your settings, and you link it appropriately.

Now, what if you want to grant the service account that this service uses on every computer the right to “Log On as a Service” ? You could put that in the same GPO, but it would override any other policy that has “Log On as a service” defined and is applied before this one. Wouldn’t it be nice to be able to specify in a GPO that the service account must have “Log on as a service” while keeping the currently specified rights?