New for Server 2008 R2 and Windows 7 is the AD admin center (part of the Windows 7 RSAT). A UI based on PowerShell, ADAC provides a slightly richer experience over the MMC-based ADUC. Object-related tasks are clearly visibly, object properties are consolidated in a single flowing pane, multiple domains can be seamlessly managed, and new query abilities make up some of the major improvements.

All aspects of a computer or user object can be managed from one intuitive interface, although a majority of the tabbed extensions still exist in the new pane. Account, Org, Member of, and profile were broken out separately.

Another nice feature is that you can quickly view many advanced details about an object such as last log on, SIDs, USNs, and GUIDs.

Filtering allows administrators to perform searches through the directory to quickly determine many details such as disabled or locked accounts, accounts that haven’t logged on in x days, etc.

I’m not sure I’m ready to give up ADUC just yet for ADAC but I’ll keep playing to possibly uncover additional value.

A few minor things have changed since the RTM build of 2008 R2 dropped with regard to this feature. Here is a quick recap and overview.

First your domain must be running in Server 2008 R2 forest and domain functional level, which means all of your DCs must be running 2008 R2.

Once this is achieved you will be allowed to enable the recycle bin AD feature (which must be done from the DC holding the Domain Naming master role).

To verify that the feature was successfully enabled fire up ldp.exe in admin mode. In the 2008 R2 RC the deleted objects container was now visible but in RTM it isn’t. Hit View—>Tree—> and select the Configuration partition for the BaseDN. Expand down to the Partitions container and verify the recycle bin has been enabled under msDS-EnabledFeature.

Ok good, the feature is enabled but we still can’t see the deleted objects container nor any objects that we delete at this point, even though the container is visible in the well known objects list. This is because the container itself is marked as deleted. Deleted object restore or view operation attempts will fail at this point as well.

To change this, with the domain root selected as BaseDN, click Browse—>Search, enter CN=Deleted Objects,DC=domain,DC=com for the Base DN, change the filter from * to user, then click options. Change the search call type to extended then click the controls button. In the “Load Predefined” drop down select “return deleted objects” and double-click the 1.2.xx item in the active controls pane. Click Check in, then Ok. The TechNet link at the bottom goes into greater detail about this.

Refresh the tree and you should now see the deleted objects container. You should now be able to view and restore your deleted objects via ldp or PowerShell.

Reference:

TechNet

I originally had a bit of trouble with the betas of XP Mode but the Release Candidate is polished smooth and fully functional. XP Mode is comprised of two applications: Virtual PC and XP mode. Virtual PC can still be used to run a multitude of custom VMs but consumers will get XP Mode for free. This includes a fully licensed XP Pro VM and some very cool application virtualization features as well. Virtual PC, most notably, now supports USB drives and smart cards. Tighter host integration is achieved by more integration features and host hardware device access. An important distinction of this version from its predecessors is that CPU hardware virtualization is required. Your CPU must be capable of running the AMD-V or Intel-VT instruction set to use the software.

Having a fully licensed XP Pro VM at your disposal has a lot of obvious benefits. Any legacy application incompatibilities can be remedied by installing in the XP environment. The concept of virtual machines may prove troublesome to some end users in the enterprise so as part of XP Mode, full published application virtualization is available as well. Any application installed in the XP Mode VM is, by default, automatically published to the XP Mode Applications folder in the start menu. 

You can easily publish any application you want by creating a shortcut in the “all users” folder on the XP VM. When XP Mode applications are launched the VM cannot be running. If you attempt to launch a virtualized application while the VM is running, you will be informed that the VM must first be closed. The default action is hibernation.

Now for the magic. Using XP Mode Applications you can run two versions of the same program. conflict free, including IE! Have a web app that will only work on IE 6? No problem. Need to run Office 2007 and Office 2003? No problem. The best part is that the virtualized app is seamlessly integrated into the workflow area with no obvious indication it’s virtualized at all. If you’ve used ThinApp or the like this experience is very similar, except provided near natively.

Even from a process standpoint it simply appears that two instances of IE are running. Combined with the Virtual PC instance this solution has a relatively small footprint. YMMV, of course.

I will be deploying Windows 7 in my enterprise soon, which combined with XP Mode will provide a very solid solution. Application virtualization was previously a potentially expensive investment depending on technology and implementation. Free is certainly hard to beat, and the complexity of this solution couldn’t be any less.

I have operated in production environments with AD accounts in full-time admin mode as well as non-privileged mode (2 accounts). In a domain setting UAC can make the later tolerable by prompting you for credentials when attempting to run an application requiring greater privileges. In the XP days this was accomplished by using “Run As”. The temptation is to just turn off UAC and run as a full-time admin but I’m trying to be good and resist this temptation, especially with Windows 7 and the new security levels UAC provides.

You can find the UAC settings able to be modified via group or local policy in Computer Configuration\Security Settings\Local Policies\Security Options:

By default, Microsoft PowerShell runs in non-privileged mode, with UAC enabled, as does the command prompt. This means that if you want to run elevated commands or applications then you would need to open another session in administrative mode (right-click—>run as administrator). In UNIX this issue is addressed with the sudo command that provides temporary elevation to “super user” status to execute an otherwise restricted process. One could then define elevated accounts via the sudoers group where you can define which accounts can be used for sudo, the goal here is to not needlessly give out the root password.

We can emulate this behavior in Windows with PowerShell with the help of UAC. If you’re only looking to executed elevated processes in PowerShell without entering alternate credentials then you can ignore the UAC piece. The first step is to create a profile in PowerShell, if you haven’t already. Enter $profile in PowerShell to show the path to the profile. The MSDN link at the bottom of this entry will give more information on the various locations profiles can exist. Test-path $profile will show you if that profile exists and if it’s operational.  If the test comes back false then you will need to create the profile first by executing: