SBS: Are you redirecting the location of newly created computer objects?

Note: This isn’t specific to SBS, but larger organizations tend to already have processes in-place to handle this.

Short answer – use “redircmp.exe” for all of your SBS installs.
Need reasons? Read on…

So, by default when new computers get added to the domain, they get created in the Computers container. And it might be okay that they get dumped there because it forces someone to do something with it. Assuming you’re the only one managing it, you won’t forget, right? Oh, you might? What about you’re other netadmins, will they forget? Maybe so.

Simplify and automate…

That’s why we have Active Directory anyway, right? Well, that and to scale nicely – but doing stuff is a big part of it. So if you have computers piling up in that computer container (by now you should have opened out ADUC), then you know for a fact that they don’t get any GPO’s applied. And if dozens of boxes – for that matter, if even a few boxes – have been added without following the correct process, then at best you have some confusion. Worst-case, you have boxes that aren’t getting updates distributed via WSUS (or some similar fate).

Fortunately, there’s a tool for this called “redircmp.exe”. What it is? How do you use it? Is it safe for SBS? Don’t want to read the KB article? Well, it’s just what it sounds like – a tool for redirecting the default location of newly created computer objects (there’s a “redirusr.exe” too, which does the same for users). The first step is to probably to consider building onto the OU design of SBS. No, I’m not talking about changes to the SBS-ized stuff… we tend to build-out beneath the default OU structure for customization. Why? Well, it reduces risk - it helps us to enable our clients to do a bit of self-management sometimes – and it keeps team members from making big mistakes. But the main reason is that you probably want something that makes sense for your circumstances and your client. The hierarchy should fit the business-need.

As far as how to use it, there’s not much to it… from the SBS server just run it and it gives you the usage. Otherwise, here’s something that might make sense for you… obviously this is a sample based loosely on the SBS hierarchy.

“redircmp ou=WSUSMasterOU,ou=SBSComputers,ou=Computers,ou=MyBusiness,dc=domain,dc=local”
It should respond with “Redirection was successful.” If it said something else, check this KB article. Now go ahead and test it. Fire up Virtual PC with a base-image, add it to the domain, and refresh the OU in ADUC. It should show up down in the WSUSMasterOU (or whatever is appropriate for you). Depending on how much automation you want, this might be enough. At the very least, you're a step in the right direction – and if someone is forgetting to move it down further into the right OU, or add it to the right group, then at least you’ve got a base level of GPO’s being applied.

Group Policy: Stop creating islands of customization – using Restricted Groups to Control Local User Manager

How are you managing local groups on end-user workstations? If you answer is “I’m not… “, have you let islands of customization create a security – and configuration mess? Or worse, if you have customers that you provide service to, have you extended your internal mess across your entire client-base?

First of all, you should be making every effort to avoid giving users local admin rights. But you already know that. And you’ve probably already read the whitepapers, called the software vendors, and used Process Monitor to watch for what applications are making what changes and where. But keep in mind that this isn’t limited to how you manage the local admin group – for instance, maybe “Domain Users” isn’t the appropriate group to be capable of logging into the Account Department computers. Whatever the case might be – how should you manage your local users and groups? Group policy.

I’m always surprised by how often I hear it said that you can’t manage lusrmgr.msc via Group Policy. Because you can! And you really should be doing so. Take a look at restricted groups. Now, I know, the KB article isn’t all that great. Indeed, the fact that you use restricted groups to manage local users and groups is conspicuously missing. So look here for more information. Keep in mind that “Members of this group” lets you add groups or individual users, which define the local groups that you identify.

Now go and test it out with Virtual PC or something, before you try to implement it. Because it can be confusing – and Group Policy (thankfully) overrides existing local settings. So go create new OU in AD, make sure your test workstation lives below that OU, and scope a GPO that applies to the computer policy, at this location (GPO_name\Computer Configuration\Windows Settings\Security Settings\Restricted Groups\). Tweak it and get it right. Then you can go back and do an audit of who is already a member of what local groups (making sure it appropriate) and build a policy that reflects that reality.

Group Policy: Granting personnel the ability to Add Workstations to a domain

Whenever appropriate I like to enable people to serve themselves. I mean, do you really want your desktop support group calling you asking for domain admin privileges so they can add workstations to the domain? Of course not… nor should you be handing out domain admin privileges on demand (if you are, then you have an entirely different set of issues to deal with).

You can edit the default domain policy to allow personnel to “Add Workstations to a Domain”. Now there are other ways to accomplish this, but you can use this if you’re working with the domain policy.

1) Open Group Policy Management, and edit the Default Domain Policy.

Next, expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and select "User Rights Assignment". Double-click on “Add Workstations to a domain". Put a check-mark in the "Define these policy settings", and specify the groups (or users) that you want allow users to add to the domain.

That’s it.

Group Policy: How-To article on enabling the Windows Firewall via Group Policy

Just to follow-up on my Windows Firewall post from the other day, I found a good How-to article (via Michael Howard's blog) on configuring the Windows Firewall in SBS using group policy. Also, you might want to consider adding an exception if you use WMI scripts to manage your clients.

Group Policy: SBS Admins - Enable the Windows Firewall for your Windows XP SP2 clients

A while ago I did a post on configuring the Windows Firewall using Group Policy to get WMI scripts running against Windows XP SP2 clients. Since then it’s been on my list to do an expanded article going over the benefits of using the Windows Firewall, primarily because I see so many SBS environments that simply aren’t taking advantage of it.

So I’ll start by hitting the highlights, beginning with a financial incentive.

It’s free.

Since I’m bridging the SBS-Enterprise gap today, that’s always a good incentive for the SMB market – and something that corporations can get behind.

It works.

So there… not only is it free, but it actually does what it’s advertised to do… helps stop the spread of bad stuff… like exploits targeting vulnerabilities patched by MS06-040. Yes, it only filters incoming traffic, but that beats not filtering any day of the week. Vista should do outbound filtering, but that's a subject for a different day.

It gives your Patch Team space to evaluate before patching.

Oh, you are the patch team? Even better… because you really should test those patches before firing them off to your entire customer base. If you’re not testing, come up with a plan to start testing. In the mean-time, start following the newsgroups, mailing lists, and web sites that give the play-by-play on new patches. Check out this link for some patching resources that I follow.

You can specify a different firewall profile depending on how the computer is connected.

Check out the Group Policy editor (gpedit.msc). You have two profiles: the Domain profile, and the Standard profile (you can find these in the Group Policy editor here: Computer Configuration>Administrative Templates>Network>Network Connections>Windows Firewall.). When enabled, the Domain profile gets applied when the computer is connected to the domain - specifically, when it sees that the DNS suffix matches your domain configuration. The standard profile can be enabled when the computer is not connected. We started out (quite a while ago), by dogfooding this with internal users – mostly developers and IT Pro’s that would readily articulate pain points. Then we turned it on for internal use, and begun tightening it down.

Doesn’t enabling the Windows Firewall break-stuff?

It can. But internal testing, can really help alleviate, if not eliminate problems before a widescale rollout.

Did it break anything for you?

Not much. One thing that we did uncover was a “Scan to desktop” application that had developed quite a cult following in the office. Anything that got scanned on the scanner showed up on the desktop of the user doing the scanning. Very typical for the corporate environment … but not nearly as common in your average SBS environment. Testing revealed it prior to rolling out the Windows Firewall across the organization, and an appropriate exception was created for it.

How do you enable the Windows Firewall?

This could probably be better answered with a short How-To. This link can at least get you started; in the mean time I’ll see if I can either link something up, or create a How-To. The short version… in ADUC, create a new OU below your current “SBSComputers” OU. Throw your test computers into that OU, then turn on and configure the Windows Firewall Domain Policy using the Group Policy editor for that specific OU (Computer Configuration>Administrative Templates>Network>Network Connections>Windows Firewall). More better ways exist - but this is good for a quick and easy test ;).

Also - remember that Group Policy refreshes for Users and Computers are every 90 minutes. So you might want to do a "gpupdate /Force /Sync /Boot" on one of your test boxes to verify that the Windows Firewall gets enabled.

Citrix: Deploy ICA client via Group Policy

Referring back to my last post, one thing I did run into is that the Citrix Program Neighborhood (PN) doesn’t act quite the way you'd exepect after you deploy the client via GPO… no matter what get's specified in the custom build (msiexec /a Ica32Pkg.msi), PN ends up on your system… with a shortcut on your desktop (no thnk you).

The Citrix article CTX105642 explains it, and has a good work around... use ORCA to remove the shortcut and PN install… grab a copy of ORCA here if you don’t want to download the entire SDK.

Group Policy: Why aren't more SBSers using Group Policy for stuff?

One thing that I see going way underutilized in the SBS world is group policy.

And no – I’m not counting what’s pre-configured to automagically “just work” in SBS. I’m talking about leveraging group policy to deploy your apps, utils, and other updates –whenever possible.

So the reason that I was reminded of this today, is because I was working with a large customer who needed to deploy a Citrix ICA client to a bunch of systems. I was talking to my SBS admins who were throwing out ideas like… scripting it, RDP/TS into individual systems, etc. And I was just beside myself because, well… Group Policy rocks! Deploying a tool like the ICA client to oh… two hundred systems with almost zero effort is a blast! Besides, why would I want to make this more difficult than it needs to?

So I was thinking… perhaps SBSers are intimidated by Group Policy… could that be? I don’t know... tag that as SBS-intimidation... because if they are, then they need to start hitting the lab more often. In fact… they better have just been too scared or lazy today because dang it, group policy shouldn’t just be overlooked!

Use the tools we have… especially when they're powerful, and free!

Oh, and if you’re on SBS… and you want scope some GPOs, I recommend adding OU’s below what’s pre-configured in SBS. Don’t muck with the SBS OU’s unnecessarily. It’s just not a good idea – especially if you’re not sure what you’re doing!

Group Policy: Blocking Outlook Express via Group Policy

Blocking users from running Outlook Express on their computers is probably a good security practice for many organizations.

Doing so is a simple matter of opening the group policy editor, and browsing to the following location:

User\Administrative Templates\System\Don't run specified Windows applications
The executable name for Outlook Express is “msimn.exe”.

And remember, you can test the application of this GPO on a small group by just applying it to the appropriate OU, and then enabling security filtering for a group that contains users who would be good to test with.

Group Policy: Windows Firewall setting to allow your WMI scripts to run

Let’s go back to the architecture assessment that I was talking about earlier this month. One thing that I encountered, and commonly see, are improperly configured group policy settings for the Windows firewall.

“SP2 has been deployed for quite a while - why are you talking about this now?”

Well, because I was reminded of this just recently and needed to document it. :) So, part of the assessment involves to running a series of scripts against the new customer environments (I’ve posted snippets of the workstation inventory script). And one of the things that get turned off by default is called “Remote Administration”; and this prevents me from running WMI scripts.

For most organizations, it’s a good idea to enable the Windows firewall under the domain profile. In organizations where you need to be able to do things like talk to clients via WMI (which would be a type of unsolicited DCOM request on port 135), you have to make sure that you enabled the group policy object to “Allow Remote Administration Exception” (Open up Group Policy Manager, and go here under your Computer objects OU - Computer Configuration\Administrative Template\Network\Windows Firewall\Domain Profile).

Once you enable "Allow Remote Administration Exception" (and the computer objects refresh their policies), you can start running your scripts again.