Posts

Windows Server 2008 R2 Recycle Bin (Part 1)

Had a very interesting conversation about the new Server 2008 R2 version. Most IT admins know it’s been updated with new features, and the one question that usually comes up is- “Doesn’t this mean I won’t need third party apps?”
Well, no, you still do. Really. For example, let’s look at one of these new features, the Recycle Bin.
Remembering the basics:
-Deleted objects in Active Directory aren’t deleted immediately
-Marked with a “tombstone” flag- replicated to all DCs
-Tombstoned objects are saved for a while – 180 days by default
– When deleting objects, Active Directory removes most of its attributes
Windows Server 2008 R2 introduces this change to the deleting process: It places your objects into a “deleted” state where their system attributes are left intact (non-system attributes are stripped out). Recovering an object (changing the tombstone flag) is made easier AS LONG AS THE OBJECT EXISTS IN THE TOMBSTONE.  Following the default 180 days in the tombstone, if no changes are made the object becomes “recycled” and its attributes are stripped out, so it can no longer be recovered.
So this should be very easy right? Well, if you’re trying to access a deleted object with your native management tools you can’t, even with all the changes in Server 2008 R2. Recovery is still not an easy task. Despite the name, you won’t see an AD “Recycle Bin” on your desktop or in any other directory. You’ll have to continue using low level directory editors, scripting or other more complex ways of recovering (reanimating)objects from their “deleted” state. Oh, and by the way, you CAN’T use this new feature until every DC has been upgraded to this new version of Windows (Server 2008 R2 specifically).  What does this mean to you? You have to:
– Upgrade every domain you have to the Windows Server 2008 R2 functional level
– Upgrade your forest to the Windows Server 2008 R2 functional level
(more on this in Part 2)

Server 2008 and Terminal Services

Quick note on some new improvements in Server 2008 vs 2003/2000 that some people may still not be aware of. Some or all of these may provide a compelling reason to migrate.

 

Server 2008 includes enhancements to many current Windows Server features. Terminal Services is one of them. In Windows Server 2008 it has been enhanced to provide more functionality when compared with the previous versions. Some of these improvements are:

 

– Easier to install and configure

Application publishing

Seamless windows and session sharing

Published applications can be accessed using a built-in web interface

Applications can be accessed securely from outside the firewall without an SSL VPN or modifying firewall configurations, using HTTPS tunneling

Enhanced printing

Session-based load balancing

32-bit color and new RDP compression

Display data prioritization

Large display and custom resolution support

Support for monitor spanning

Enhanced Plug-and-Play device redirection

Single Sign-On

 

Having all these improvements, Terminal Services should be more appealing to IT organizations wanting to reduce complexity in their deployment scenarios.

 

A few things you must keep in mind when you consider migrating because of the above improvements:

 

Most of Windows Server 2008 Terminal Services’ new features require Windows Vista SP1 or Windows XP SP3 on the client side. As a result, these features are not available for older platforms.

To benefit from all the new features of Windows Server 2008 Terminal Services you must upgrade all your servers to this version.

Windows Server 2008 Terminal Services provides session-based load balancing capabilities that are only for groups of identical servers.

Server 2008 and the RODC (Read-Only Domain Controller)

Speaking to several people about the Server 2008 migrations, there were a lot of questions and reactions to the new Read-Only Domain Controller (RODC) option. Some confusion too, as some thought this is similar to Windows NT 4.0’s Backup Domain Controller (BDC) type technology.

 

The difference between a RODC and a BDC is apparent when there are more than two DCs per domain. In Windows NT 4.0 you could only have 1 read-write Primary Domain Controller (PDC), and the other DCs had to be read-only BDCs. Windows Server 2008 allows you to choose which DCs are read-writable and which are read-only with a great degree of freedom. By example, if you have 30 DCs in your domain, you can have 26 regular DCs and 4 RODCs.

 

One reason for having an RODC is if you have a DC that is not physically secure. In that case, not only could data be obtained from the DC, but malicious data could be injected into the vulnerable DC. With a normal read-writable DC, such damage would replicate throughout the domain and maybe even through the entire forest. By having an RODC the damage could be localized.

Group Policy best practice analyzer tool

This tool has been available for about 1 year or so. Many people are aware of it, but we talk to many other IT folks that either chose to ignore it or are simply unaware of it.
According to Microsoft- You can use the Microsoft Group Policy Diagnostic Best Practice Analyzer (GPDBPA) tool to collect data about an environment’s Group Policy configuration. For example, you can use this tool to analyze a Group Policy configuration for the following purposes:
• To search for common configuration errors
• To discover and to diagnose problems
• To collect data for archiving
The account that you use to run the tool must have the appropriate permissions to access both the Active Directory database on an environment’s domain controllers and the SYSVOL file structure that is maintained on those domain controllers. Additionally, the account must have local Administrator permissions on the Group Policy client.
There are two additional prerequisites for using the GPDBPA tool:
• The Microsoft .NET Framework version 1.1 or a later version must be installed on the computer on which the GPDBPA tool is installed.
• The Windows Management Instrumentation (WMI) service must be running on the environment’s domain controllers.
Our Active Directory Manager has a robust built-in Group Policy management module. Contact us for more info about this or any of our other solutions.

Quick note about Group Policies – Server 2003 vs. Server 2008

A major issue in Server 2003 implementations of Group Policies is the huge amount of space they take up. For each Policy, there’s a corresponding .ADM file. The .ADM file supports only the English language, and it’s also 3.5MB in size. Not much right? When you consider that for each policy you have, there’s a new .ADM file and another 3.5MB, you can see how this can get out of control. For example, let’s say you have 200 policies– that’s 700MB of extra data that you have to back up. Even if you only have 100 policies, that’s still 350MB.
Server 2008 offers a new way of dealing with this issue. In Server 2008 you can use ADMX files, which are based on XML- more lightweight by comparison. With the new ADML files, you now also have multiple language support.
The Active Directory solutions we provide will help with your Group Policies management. Contact us for more information.