Server Core and UAC

We have just finished replacing our file server that was running on Windows 2008 Standard Core.

Replacing that server was not high on the priority list until after our migration to SBS 2011 RTM when we had a Group Policy setting that enabled UAC for the OU that contained our Core and Hyper-V Server installs. We restructured our GP scopes and OUs to eliminate UAC on our Core based servers.

By default, UAC is disabled on Server Core. All of our Core, Hyper-V Server, and cluster node servers took the settings changes that disabled UAC without an issue. But, the file server for whatever reason decided to ignore the GP settings and keep UAC enabled.

Try as we might we ended up with a Group Policy Tattoo for UAC thus rendering the server in a bad state.

We decided to cut and run so we reloaded it with Windows Server 2008 R2 Standard Full.

The benefits of having the full install are huge. We now have access to the Windows Search service which allowed us to key in all of the shares on the file server into the Windows 7 Libraries feature and thus local search results.

We were able to mount the original server’s backup and attach the backup VHD to recover the needed folder share data.

It also allowed us to gain access to the File Resources management features which will help us to clean up our file stores:

The above screenshot was from a folder specific to Windows 95 . . . yeah, I actually said “Windows 95”! :)

The utility is the Enhanced Print Troubleshooter developed by the Decision Theory Group at Microsoft Research and Microsoft Product Support Services (PSS).

From the ReadMe.txt:

The Enhanced Print Troubleshooter is a diagnostic tool developed by
the Decision Theory Group at Microsoft Research and Microsoft
Product Support Services.  The Enhanced Print Troubleshooter uses
probabilities and costs associated with different faults to generate
a list of recommended troubleshooting steps.  When you run the
Enhanced Print Troubleshooter, the list of recommendations is
regenerated after each question is answered, based on what the
system knows about the problem you are having and the printing
configuration.

We will now be able to create and run reports that will allow us to see the big picture on all of those dormant files as well as other files and their usage on the server. Since we have well over a Terabyte of data to sift through we are anticipating freeing up a lot of storage space!

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*Our original iMac was stolen (previous blog post). We now have a new MacBook Pro courtesy of Vlad Mazek, owner of OWN.

Windows Live Writer

SBS - Group Policy and "Tattoos"

When we need to setup Organizational Units (OUs) and Group Policy Objects (GPOs) for a client's particular Active Directory security needs, we need to be aware that security structures implemented via Group Policy can be permanent.

We call this a "Group Policy Tattoo".

The Tattoo is one of the main reasons why it is important to test out Group Policy setups either virtually with Undo Disks enabled, or at least via a Test OU on the production box with a disposable PC or laptop.

Why does the physical PC or laptop need to be disposable?

Because, if we make a Group Policy setting mistake or things do not work out as we expected, then we can reinstall and start again.

Given the amount of time needed to reinstall the physical machine every time something doesn't work out the way we expect it, there is a pretty clear justification for having that TechNet Plus subscription with your TechNet Eval versions of SBS, XP, and Vista boxes virtually installed on a dedicated Virtual Server box. Having the UnDo Disks feature enabled means that there is an ability to go back to the system state before the GP changes with a minimal wait time.

Here is a link to Darren of GPOguy.com's excellent article explaining some of the finer details of Group Policy "Tattooing".

It always pays to keep in mind that when we are considering the possibility of setting restrictive GPOs in place that they may be permanent.

This is especially important for the client to understand as systems that are affected by the restrictive GPOs when placed in the respective OU may need to be reinstalled to defaults if they are to be moved to another OU or location at a later date.

Darren also has another excellent post on Restricted Groups policy and their caveats that is worth a read.

It is important to reiterate: If we mess up a client's production setup with an OU/GPO gaff, we may be on the hook for a huge amount of time to repair the damage.

As always: Test ... test ... test!

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.