Search This Blog

Tuesday, February 23, 2010

You can't empty the Trash or move a file to the Trash


In Mac OS X, each user account has a separate, invisible Trash folder that is in the home folder. When you view contents of the Trash, you see only items you placed there and not the Trash folder of any other accounts. If other writable volumes are present, you may also have individual Trash folders on these volumes.

How to delete a file

  1. Drag an item's icon to the Trash (in the Dock), or select the item and press Command-Delete.
  2. Choose Empty Trash from the Finder menu.

Note: If you're trying to delete a file that wasn't completely downloaded or copied, check out this document.

Tip: In Mac OS X 10.3 or later, you can securely delete items by choosing Secure Empty Trash from the Finder menu.

If you change your mind about deleting the item before you choose Empty Trash:

  1. Click the Trash icon in the dock.
  2. Drag the item out of the Trash.
     

If you can't empty the Trash or move a file to the Trash

For example, this message might appear when you try to empty the Trash: "The operation could not be completed because the item '(item name)' is locked."

First, try holding the Option key as you choose Empty Trash from the Finder's File menu.


Otherwise, check for these conditions:

  • Is the file locked?

    If files are locked, unlock them before deleting or delete using the tips in the "Deleting locked files" section below. Also, see this article.
     
  • Do you have correct permissions to modify the file?

    Every file and folder in Mac OS X has some permission settings to help define what you or other users can do with the file or folder, for example whether you may modify it or not. If see an alert box with a message that says you do not have "sufficient" privilege or permission, see the tips in the "Emptying the Trash" section of this article.
     
  • Does the file or volume have special characters?

    Usually, Mac OS X can delete files whose names contain special characters, but sometimes you might need to follow this advice.

    1. Note the name of the volume which the files are being deleted from. If you are not sure of the item's location, you can verify that by selecting it then choosing Show Info from the File menu. If the name of the volume contains any special ASCII characters, such as a bullet or trademark character, temporarily rename the volume so that it does not contain these characters.

      Example: If you cannot delete files from a volume named "·Dox", rename the volume to "Dox". After the Trash is empty, restore the volume's original name as desired.
       
    2. Examine the name of the files or folders you cannot delete. They should not contain a solidus ("slash", "/") character or any other special ASCII character such as a trademark, quotation mark, or copyright symbol. If the file does, remove the special character or slash from its name, then delete it.

      Example: If you cannot delete a file named "Things/stuff·", rename the file to just "t", then delete it.


Deleting locked files

Locked files can easily be deleted if you press Shift-Option or Option key combination while emptying the Trash (in Mac OS X 10.1 and later). For Mac OS X versions 10.0 to 10.0.4, use Show Info to deselect the item's Locked checkbox.

If you still cannot delete the item, start up your computer from the Mac OS X installation disc and choose Disk Utility from the Installer menu of the first screen. Use Disk Utility to verify and, if necessary, repair your disk.

If a file can't be unlocked, you may not have permission to unlock it. See this article to learn how to get write permissions.

If the issue persists, use Disk Utility's Repair Permissions feature to check your Mac OS X volume. For Mac OS X 10.1.5 only, download and use Repair Privileges Utility 1.1 instead.


Advanced tip about deleting locked files

If there are several locked files in the Trash, you can unlock them all at the same time at the command line. Follow these steps:

  1. Open Terminal. It's located in /Applications/Utilities.

    Type: chflags -R nouchg

    Note: Type one space (not pictured) after nouchg in the line above, so that it ends in "nouchg ". Do not press Return yet.
     
  2. Double-click the Trash icon in the Dock to reveal the contents of the Trash. If necessary, arrange the Finder window so that a portion of the Terminal window is still visible.
  3. Press the Command-A key combination to select all files in the Trash.
  4. Drag the files from the Trash to the Terminal window.
    Note: This automatically enters the pathname for each file. This eliminates the need to individually empty multiple Trash directories, particularly when multiple disks or volumes are present.
  5. Press Return. No special text message will be shown indicating that the command was successful.
  6. Empty the Trash.

If the Trash does not empty or if you see a message in Terminal that says "usage: chflags [-R [-H | -L | -P]] flags file..." you most likely did not type the text in step 2 as indicated or did not leave a space. Repeat the steps if this happens.

Creating, Targeting, and Applying Group Policy Preferences

Creating a new Group Policy Preference (GPP) begins in much the same way as creating a new Group Policy. Start the process by launching the Group Policy Management Console (GPMC) on a Windows Vista (or greater) or a Windows Server 2008 (or greater) computer. This may require the installation of the Remote Server Administration Tools, which can be downloaded from Microsoft's Web site. While the settings GPPs can be used by down-level clients as far as Windows XP, the actual creation of the GPP must be done using the GPMC on one of these operating systems (OSs).

Once launched, right click Group Policy Objects and choose New to create a new GPO. Name that GPO and leave its Source Starter GPO field blank. Once created, right-click the new GPO, and choose Edit to bring forward the Group Policy Management Editor (GPME). In this example, we will create a set of GPPs that apply to particular sets of users. To do so, we will use the preferences found under User Configuration. Here, three settings will be configured for users. Although these scenarios may outwardly appear quite complex, they are representative of situations that are likely to arise in your own environment:

  • The H drive must be connected to the user's home folder at \server1financehome for all users in the Finance Global Group.
  • The TEMP folder must be relocated to C:MyTemp for any users which have the home-grown application named CustomerApp installed on any computer where they login.
  • The shared printer at \server2printer1 will be automatically connected for any users on the 3rd floor. This floor has already been configured by network engineers to use an IP subnet which includes addresses from 192.168.3.2 through 192.168.3.254.

Each of these settings will be contained in a single GPP, which will be linked to the Users OU. In this domain, all users are a member of the User

Example 1: Enforcing a Mapped Drive

In this first example, the H: drive for Finance users contains sensitive information and must be segregated onto a separate server. Because of this separation, the GPP needs to verify if the user is a member of the Finance Global Group before connecting the mapped drive. This example is representative of the complex requirements administrators are often asked to encode into login scripts.
To accomplish this with a GPP, right-click User Configuration | Preferences | Windows Settings | Drive Maps and choose New | Mapped Drive. Fill out the resulting wizard screen as shown in Figure 1. You'll see that a location, drive letter, and label can be set, as well as configurations for alternate credentials. The drive can be hidden or displayed depending on your needs.

Figure 1: Creating a mapped drive for finance users.

Important here is the value for the box marked Action. While specific options can be different based on the type of configuration to be done, four options are most generally available:

  • Create. This action will configure the preference if the setting does not already exist. If the setting exists, no action is taken.
  • Replace. This action deletes and recreates the setting.
  • Update. The update action is the most powerful, as it accomplishes the greatest amount of actions. This action creates the setting if it does not exist. If the setting exists, it updates the setting per the preference.
  • Delete. This action removes the setting.

This first step configures the action that will be accomplished. The next step is to configure which users will actually receive the preference setting. Remember that this setting is one of three that reside in the same Group Policy Object that will be linked to the Users OU. To target this setting to just those users in that OU who are members of the Finance group, first click the Common tab. In the resulting screen, select the check box next to Item-level targeting, and click Targeting.

This action presents the Targeting Editor. Using this editor, it is possible to individually target each setting to users and/or computers based on a set of parameters. These parameters can be the computer's name, or IP address range, operating system, or installed applications. Twenty-seven parameters are available in total to specifically target each individual setting.

Figure 2: Targeting the mapped drive to only the Finance group.

In this first example, the drive mapping needs to be targeted only to users in the Finance Global Group. Do this by clicking New Item and selecting the Security Group parameter. This will add that parameter to the list as shown in Figure 2. Click the ellipses (…) button to enter the Finance group's name to the parameter. Figure 2 shows how the users in the CONTOSOFinance group have been added to the targeting editor. Click OK twice to complete the wizard and the first example.

Example 2: Setting a New TEMP Folder for an Application

The second example shows how the needs of a specific application can be fulfilled through a GPP. Here, the application called CustomerApp requires a special location for its temporary files, set to C:MyTemp. This is not the default temporary files location for the Windows operating system, and thus should only be configured for those users who have logged onto a computer where this application is located.

By configuring this setting under User Configuration, we can ensure that the remapping of the TEMP folder follows users as they login to multiple computers around the network. Here, any computer that is logged into by a user who receives this policy will have the TEMP folder changed.

Accomplishing this task starts in the same way as the first task, with creating the Environment properties setting within the GPO. Do this by right clicking User Configuration | Preferences | Windows Settings | Environment and selecting New | Environment Variable. The wizard for creating environment variables is less complex than those for drive mappings, as fewer configurations are required. Figure 3 shows an example of how this wizard should look when filled out for this example.

Figure 3: Updating an environment variable for an application.

As before, this step only sets the configuration. The next step is to specifically target this configuration to the right users, a process that is once again done within Item-level targeting. Different this time is the parameter that will be used in targeting the preference setting. This time, click on New Item | MSI Query to create a parameter that searches for the presence of an MSI application on a computer.

In this example, the CustomerApp application was installed via MSI to the same computer where the GMPE is being run. Clicking the ellipses (…) button brings forward the list of installed applications on the computer, where the CustomerApp application can be selected. Selecting this application adds its product code GUID to the parameter as shown in Figure 4.

Figure 4: Targeting the TEMP folder environment variable change to occur only when computers are installed with the CustomerApp application.

Multiple query and target types are available using this parameter. This granularity provides for specific versions of a product or even MSI properties to be matched for rich targeting. Even patches or components of a product can be targeted by changing the value of the target type field. Click OK twice to complete this configuration.

Example 3: Connecting a Printer Based on Location

The final example preference setting is one that has been long desired by Windows administrators: The ability to configure printers based on a user's location. This is a capability that has been possible using traditional login scripts, but was difficult to encode properly into their textual logic. I have seen login scripts geometrically increase in size and complexity as organizations attempt to add location-based printer logic, to the point where they became challenging to debug down the road.

Group Policy Preferences alleviates this once again through its capacity for extremely granular levels of item targeting. Obviously, some differentiation must be made between computers in geographic locations for this type of targeting to work—differentiation that must occur outside the GPP infrastructure. But, if you have a way to isolate sets of computers from each other, this is a handy solution for making location-based configurations such as printer mapping.

In this example, the differentiator between computers is the subnet. Here, network engineers have divided a three-story building into three different subnets, with the first floor using 192.168.1.0, the second floor using 192.168.2.0, and the third floor using 192.168.3.0. This separation by subnet is a common occurrence in many businesses, and often makes for an excellent identifier to use in location-based configurations.

For this third example, the shared printer at \server2printer1 should be connected any time a user logs into a computer on the third floor. Once again, by targeting this preference to users, it is possible to fulfill the needs of roaming users as they login to multiple machines across many locations.

Figure 5: Setting a default printer based on location


Configuring the printer itself happens by right-clicking User Configuration | Preferences | Control Panel Settings | Printers and choosing New | Shared Printer. In the resulting wizard (see Figure 5), the shared printer at \server2printer1 is configured and set to be the default printer.

As before, this step is trivial in its implementation. The real power is in the targeting of this configuration to the right computers, a process that is once again done within Item-level Targeting.

Figure 6: Configuring an IP Address Range parameter.

In this third example, the network IP address is the differentiator between floors. For the third floor of this building, the IP address range of 192.168.3.2 through 192.168.3.254 corresponds to the correct set of desktop computers. As shown in Figure 6, adding a new IP Address Range parameter can be used. Click OK twice to complete the wizard.

Multiple Targeting

To this point, the examples here have discussed how targeting can be accomplished against a single parameter. However situations often arise where multiple parameters are necessary to fulfill the needs of targeting for a preference setting. GPP's Targeting Editor provides a limited set of logic for creating and linking multiple targeting parameters for these complex needs.
GPP's Targeting Editor provides three logic operators and a collection operator for connecting multiple targeting parameters together. Those logic operators are AND, OR, and NOT. The collection operator enables verifying whether the value of each parameter in a group is TRUE. Figure 7 shows how five different targeting parameters can be gathered together for a highly-targeted preference setting.

Figure 7: Aggregating multiple targeting parameters for very precise targeting of a preference setting.

Always remember that this capability for precise targeting of individual GPP settings must be handled with respect to where the Group Policy Object will eventually be located as well. Collections of GPPs are all a component of a GPO, which in and of itself must be linked to an OU if it is to be applied to objects within that OU. Any targeting parameters that are configured within each GPP's settings will be ultimately limited by that OU linkage.

Using Group Policy Preferences to Control Software Settings


Group Policy Preferences' (GPPs') abilities to eliminate your login scripts and bring customizable control to your user's workspace make it an exceptionally useful tool. Its no-added-cost price point accentuates that usefulness, most especially in today's "use what you already have" economy. Yet it can be argued that GPP's greatest power has yet to be discussed. That power comes in complete control over the applications that make up your environment.

One of the long-held limitations with traditional Group Policy related to the types of elements that it could configure. Right out of the box and without custom coding, traditional Group Policy could easily customize Windows settings. But its capabilities were relatively limited to just those configurable elements that Microsoft made natively available. Controlling the configuration of Internet Explorer was possible because IE is a Microsoft product, and as such templates for its configuration are provided. But if you needed to control the configuration of WinZip, or Adobe Reader, or the last article's home-grown CustomerApp application, you were forced to code your own template files or do without.

This problem goes away with GPPs. Creating a preference setting using Group Policy Preferences creates a container in which multiple custom configurations can be entered: Files can be added to computers, INI files can be modified, and even registry keys can be altered to suit your needs.

This customizability grows exceptionally useful when you align their capabilities with how most applications store their configurations. Think for a minute about the applications in your environment. When you click the check box in Microsoft Word to disable its grammar checker, or when you configure WinZip to use Classic Mode, where are those selections stored? More often than not, they're stored as values in the registry. Sometimes they're stored in an INI file. Using GPPs, both INI files and registry settings can be manipulated through the Group Policy Management Editor (GPME).

The hard part is in identifying which registry keys or INI files relate to which settings. Once you check a box, which registry key is changed, which INI file is updated? It is entirely possible to manually scan the registry for changes as you flip switches inside an application's GUI. While many applications store their settings is easily-recognizable locations (with subfolders of HKEY_CURRENT_USERSoftware as a common location), this process grows much more cumbersome when applications don't behave in standard ways.

It is in this activity where tools outside Group Policy can come in handy. Multiple tools are available on the market today to watch the registry and report on changes that occur. One tool in particular that assists and can be obtained for no cost is Scalable Software's freeware WinINSTALL LE, downloadable from http://www.scalable.com. This tool is outwardly designed as a solution to assist with repackaging software for distribution through an automated deployment solution like Microsoft's System Center Configuration Manager or Group Policy Software Installation. But one component of it can also be used as a tool to help identify which registry keys change when settings are changed in an application.

Other tools are specifically designed for registry monitoring and comparison, like Easy Desk Software's Registry Watch at http://www.easydesksoftware.com/Regwatch.htm and DeviceLock's Active Registry Monitor at http://www.devicelock.com/arm/.

"Discovering" Application Config Changes

As an example, let's assume that you want to prevent Adobe Reader from automatically checking for new updates. By preventing this action from occurring, you the administrator can pre-test and determine which updates work with your environment before rolling them out in a controlled fashion.

From within an installation of Adobe Reader, navigating to Edit | Preferences | General brings forward an option marked Check for updates. This box is checked by default, which instructs the application to automatically check for updates at regular intervals. You wish to remove this check box across every installation in your domain to prevent this action from occurring.

Figuring out what part of the registry is changed by altering the check box is one activity where a registry comparison can assist. Using such a tool, a snapshot of the computer can be taken with the check box marked, followed by a second snapshot of the computer after the check box has been cleared. Such a tool will scan the registry and locate the exact registry key and location which changed between the two snapshots. The resulting information can be directly imputed into a GPP with the ultimate result of bringing that configuration under centralized control.

What Are the Differences Between Group Policy and Group Policy Preferences


Imagine a world where every facet of your desktop environment is controlled, locked down, or otherwise centrally managed. In such a world, your corporate policies and indeed your every whim are explicitly defined for your users. You, the administrator, wield complete power in ensuring the safety, security, and functionality of your computing environment.

Such a situation would be an IT administrator's nirvana: Tired of poorly-written screen savers that consume resources and crash machines? Lock them out! Long for drive mappings that follow users wherever they go without the inconsistencies of login scripts? Enforce them! Yearn for a way to control the settings of applications (even third-party and custom applications!) to protect your users and ease your job? Cram them down, policy-style! With such complete power, you the all-powerful administrator could prevent problems from ever happening, ensure the highest reliability for your computing infrastructure, and in the end score that huge raise at your next annual review.

Does this sound like imagination? It's not. Such complete control over your desktop environment is achievable today. Best of all, its achievable using technologies you already have in place. What is this all-powerful technology? It's the same Group Policy that's been available since February 17th of the year 2000, now augmented with extra capabilities in Windows Server 2008. If you haven't played with Microsoft's not-entirely-new Group Policy Preferences, read on.

Policies and Preferences, Both Are Necessary

Back with the release of Windows 2000, Microsoft implemented a centralized solution for controlling settings across desktops and servers in an infrastructure. An almost entirely client-based solution, Group Policy began its lifespan as a mechanism for controlling Windows settings from a central configuration.

It is the "Policy" in Group Policy that is fundamentally important towards how this solution works. Think first about what a policy really is. Within a business, a policy is considered, "A written statement that communicates management's intent, objectives, requirements, responsibilities, and/or standards" (Source: www.cica.ca/index.cfm/ci_id/36552/page/1.htm). Policies define the position of a business' management and are usually considered inviolate. Once a business defines a policy, its employees are expected to follow the policy if they are to remain employees.

The same holds true with Group Policies. Once a Group Policy is applied, administrators should expect that that policy will remain in place until removed. Thus, a configured Group Policy will always be enforced. Should a user make a change that conflicts with the established policy, it will eventually be reset to its correct configuration during the next Group Policy refresh interval (which is typically 90 minutes plus a random offset).

Group Policies then are excellent tools for enforcing configurations that must be inviolate in your desktop environment. These settings, such as firewall configurations, security and auditing parameters, and some desktop control settings, make sense as being policy-driven.

But alongside these inviolate settings is another grouping of configurations that perhaps don't make sense as traditional "policies": Call them "suggestions" or "recommendations" or "preferences." Perhaps you want to suggest a certain desktop background, but you're OK if users make changes later. Maybe you want to configure an application or Windows settings in a certain way but not necessarily enforce that configuration after its initial setting.

It is for these situations that Group Policy Preferences (GPPs) are now available with Windows Server 2008. GPPs are an entirely different construct than traditional Group Policies, with the important exception in that they are applied in the same ways as Group Policies. Enabling a new GPP follows the same processes done with traditional Group Policies: Create the GPP, then apply the GPP to an Organizational Unit (OU) of objects. GPP settings that relate to users will be applied to users in that OU. GPP settings that relate to computers will be applied to computers in that OU.

More than Just Preferred

Many IT administrators find themselves confused about the "Preferences" part of GPPs. Being one of the three words that comprise a GPP's namesake, these admins incorrectly believe that GPP's "Preferences" component is really its most important. In reality, GPPs usefulness for the desktop environment goes far beyond just their capacity to be optional. GPPs, in addition to being preference-capable, are also comprised of a large swath of configuration capabilities that go far beyond what you could accomplish with traditional Group Policies.

Figure 1 shows a screenshot of the Group Policy Management Editor (GPME) on Windows Server 2008 R2. Expanded here are the preference categories available for the Computer Configuration half of a sample Group Policy Object (GPO). Here, you can see that a sample GPP can centrally manage and control elements previously unavailable with traditional Group Policies. Environment variables, files, folders, registry settings, local users and groups, printers, services-all of these elements in Figure 1 can be custom controlled through a GPP.

Figure 1: A list of GPP categories under Computer Configuration.

This list should immediately bring to mind some of the settings that you today may be configuring through login scripts. In fact, you can argue that the complete elimination of login scripts is one of the goals of GPPs. Eliminating logon scripts also eliminates the potential error that can propagate from an incorrectly-coded script. It removes your need to learn scripting languages to set preferences correctly. And, most importantly, it enables you to apply configurations in a much more consistent manner than with login scripts: No longer must you wait for users to logout and log back in to apply the script.

Further, as stated before, GPPs apply to computers in your domain in the same way as traditional Group Policies. Thus, your existing OU structure can be leveraged for GPP application in the same way that you're applying Group Policies today.

GPPs = Custom Control

Yet another design difference between traditional Group Policies and GPPs has to do with the options that are available for configuration. With some exceptions (as defined by Client Side Extensions-CSE) traditional Group Policies tend to be very on/off oriented. With traditional Group Policies, many of the selections available allow you to turn on or turn off some capability in the Windows environment.

GPPs by nature are much different. GPP settings do not have the same Enabled/Disabled/Not Configured toggle switches as with traditional Group Policy settings. With GPPs, creating a new setting effectively creates a container within which a specific change is stored. For example, in Figure 2, a new Environment setting has been created and opened for editing. Here, you can see how the Environment GPP setting provides a place to store the actual value of the Environment variable-much like you would do in a login script.

Figure 2: Using an Environment GPP to set an environment variable.

Each of the GPPs available natively with Windows Server 2008 behaves in about the same way. Let's review just a few:

  • Folders provide a place to create or delete folders.
  • Registry enables the creation, modification, or deletion of registry keys and values.
  • Network Shares enables the creation and manipulation of network shares.
  • Printers provide a place to connect network and local printers.

The list goes on. The combination of each of these categories provides a comprehensive location where virtually every facet of your desktop environment can be configured, controlled, and initially set up for your users. The result is a single location where you the administrator can establish a workspace baseline for all your desktops, setting policies where necessary, setting preferences where possible, and even enforcing certain preferences when you want absolute control.

Architecting Group Policy Preferences

Now that your appetite is whet with the potential power of GPPs, let's take a few minutes to discuss how they can be successfully implemented in your organization. First and foremost, the creation of any suite of GPP settings first requires a bit of background research. Before you ever begin creating GPPs to apply to your desktop, ask yourself a series of questions. The answers to these questions will assist you with creating the right structure of GPPs before you ever click through any wizards:

What settings do I currently control via login scripts? One major utility of GPPs is as a direct replacement for login scripts. If your organization uses login scripts (and who doesn't), GPPs provide an excellent solution for accomplishing their customization goals but with the reporting and event logging infrastructure of traditional Group Policy.

The first step in identifying which GPPs you should configure starts with a review of your login scripts. Are you mapping drives? Are you setting environment variables? Are you configuring network shares or printers for users? These and other settings can be immediately removed from login scripts and used as a starting point for your first GPPs.

What settings would I like to configure, but cannot with login scripts? Other desired settings are much more complicated to encode into login scripts, and as such are often relegated to manual configuration by field technicians. These can be ODBC connections for particular software packages, the configuration of local users and groups, or the creation of folder structures with the distribution of files.

Encoding any of these tasks into a script file that is useable by a login script is painful at best and impossible at worst. Look to your list of help desk tickets and common requests to find customizations that can be automated through their addition to a GPP.

What settings are commonly called into my help desk as problems? The metrics you may be generating through your help desk phone calls can be another excellent indicator of areas which require centralized control. Do you have applications that come equipped with the "never, never, never check this box" box? You know the check box: The very moment a user navigates through the application's Options menu and clicks the box, it breaks the application and forces a technician to visit their desk for a fix.

In these and other similar situations you can use a GPP setting to configure that box to never be checked, ensuring that the right configuration is always available for your users. Going a step further, by aligning your GPP configurations with those that cause the most pain for your help desk, you immediately gain a way to determine how successful their application can be. Apply GPPs and immediately reduce help desk calls; that's a success!

Which of these should be enforced and which should be optional? Each and every individual setting within a GPP can be set as optional or required. This is accomplished through each setting's Common tab as shown in Figure 3. There, look for the check box titled Apply once and do not reapply. By checking this box, the GPP will apply the setting once to any targeted computer, making the change on that computer. As long as the GPP setting exists it will not re-attempt to update a targeted desktop.

This check box is what brings the "Preferences" to Group Policy Preferences, and is independently set for each setting. This means that, for example, two separate environment variables can be configured, with one being a "preference" by checking the box and the other being a "policy" by not checking the box.

Figure 3: Only one setting in a GPP actually makes it a "Preference."

What is my OU configuration, and does it provide the granularity I need? As discussed earlier, GPPs are applied in the same ways as traditional Group Policies. This means that the structure of your domain's Organization Units will define how and where GPPs are applied. Today's best practices for OU structures relegate individual object types to their own OUs. This means that computer objects are typically stored in a different set of OUs than users. This separation of objects is done because both traditional Group Policies and GPPs have two halves-the "user" half and the "computer" half-with the computer half applying only to computers in the OU and the user half applying only to users (some exceptions apply, one very important example being when the User Group Policy loopback processing mode setting is configured). GPPs are no different. The user half of a GPP will apply to users in a targeted OU, with the computer half of a GPP applying to computers. GPPs do, however, have an extra power in their Item-level targeting, which will be discussed a bit later.

It is important to recognize that your domain's OU structure should be configured in a way that makes sense for Group Policy application. This can mean the distribution of users and computers into multiple OUs, or it can mean the aggregation of the same into smaller numbers of OUs. Your IT organization's needs will determine this architecture.

Is my OU structure too complicated? With the above question being answered, a second must also be asked. I present this question because in innumerable environments I've seen over years of consulting, I have found one common theme in many: An overly-complicated OU structure. Some structures were created with a desire to segregate users and computers by function, or by department, or by role. However, in these cases nothing was actually done with the objects once carefully segregated into their individual OUs.

Remember that OUs are for use by internal IT only, and in no place are exposed to the standard user. OUs are also not security principals in a Windows domain, which means that they cannot be used for applying security. Your OU structure should be defined by your need for Group Policy application in combination with any separation of duties requirements for user administration. Focusing on these two goals will ensure that you have the most flexible structure for use in configuration control.

With the answers to these questions, you can begin architecting the configurations you want to control using GPPs. Next, I'll show you how to accomplish that task.

How to Speed Up Adding Machines to Your Domain with Offline Domain Join



How many times in your IT career have you sat back and waited for the multiple-reboot process that is joining a computer to a domain. I sometimes wonder how many years of my life I've lost waiting for that multi-step process to complete.

With Windows 7 and Windows Server 2008 R2, that process gets a bit shorter with the release of Microsoft's Offline Domain Join tool djoin.exe. This tool enables Windows 7 or Windows Server 2008 R2 computers to join a domain without needing to communicate with a domain controller (at least, at first). Exceptionally useful for massive desktop rollouts, this tool comes in particularly handy when automating the deployment of virtual desktops. Here's how you'll use it:

Step one requires the use of a domain-joined computer. This computer, which will be referred to as the provisioning computer, works with a domain controller to pre-populate information about the offline computer. From the provisioning computer, run the following command to create the necessary provisioning file:

djoin /provision /domain <domainName> /machine <offlineMachineName> /machineou <TargetOuToCreateAccount> /savefile <fileNameWithTxtExtension>

Running this command creates a text file that includes the necessary information for later adding this computer to the domain.

Step two involves copying the file you created in step one to the client computer, which has not been joined to the domain.

Step three completes the process by ingesting the information in the copied file into the offline client. This is done by running the following command on the offline client computer:

djoin /requestODJ /loadfile <fileNameWithTxtExtension> /windowspath %SystemRoot% /localos

Once complete here, reboot the computer to join it to the domain. You can further automate this process by adding a little scripting around the domain join steps, or even including its information in an unattend.xml file.


Your Mail works best with the New Yahoo Optimized IE8. Get it NOW!.

How to Upgrade Your Active Directory Domain to Windows Server 2008 R2


Upgrading Windows domains isn't a new process. In fact, long-lived domains may have undergone this task as often as twice already: Windows 2000 to 2003, and later from 2003 to 2008. Although the changes an upgrade incorporates into your domain are dramatically different from version to version, the process in actually completing the upgrade hasn't changed much over the years.

The central problem, however, with domain upgrades is that they don't happen all that often. If you missed any of the previous upgrades, preferring to remain at an old functional level, then it's been somewhere between 2 and 7 years since you last thought about domains and functional levels.

As a result, this tip isn't necessarily going to teach you anything new. But what it will do is serve as the step-by-step reminder for how to get through your own upgrade process. The process has six rough steps, each of which you'll want to follow to ensure the highest level of success.

Step one: involves running a series of sanity checks on your domain. I call these verifications "sanity checks" because they use a series of tools that verify the basic health and well-being of your domain. With a domain upgrade doing many different and major things to your domain all at once, you'll want to ensure that you start its processes with the healthiest and sane-ist domain possible.

Three sanity check tools immediately come to mind for this verification, although others might be useful for your own preparation. The first is dcdiag.exe, which is available on the Windows Server 2003 media's Support Tools installation. It is natively installed to Windows Server 2008 computers and can be run directly from the command line. Dcdiag.exe runs a series of diagnostics on your domain that verifies DNS functionality, AD configuration, sites and services, and schema health among others. For each test, the diagnostic returns a "passed" or "failed" response. You should not upgrade your domain (or even move to the next step in this process) until it passes each test to your satisfaction.

The second tool verifies the status of inter-domain controller replication. Running repadmin.exe /replsummary generates a summarization of replication status across each domain controller in the domain. For each replication pair, the tool displays a status of the replication. As with dcdiag.exe, your replication should be in a healthy state before attempting an upgrade.

Gpotool.exe is your third sanity tool. Originally found in the Windows 2000 and Windows 2003 resource kits, this tool remains useful today to ensure that both "halves" of your Group Policies are properly synchronized. Remember that Group Policies store information in two places: SYSVOL and your AD database itself. If at any point in the past someone has made manual modifications to the Group Policy files in your SYSVOL, it is possible that they've become unlinked. That link failure can not only cause problems with your upgrade but also can be a source of Group Policy failure itself. Running gpotool.exe against your domain controllers will result in a list of GPOs, all of which should include the response "Policy OK." If you see errors in any policies, consider reviewing and even re-creating those policies before continuing.

Gpotool.exe hasn't been updated for Windows Server 2008. So, if you prefer more modern tools, you'll need to look elsewhere. If PowerShell is more your style, SDM Software has a set of freeware Group Policy cmdlets that can perform many of the same verifications as gpotool.exe as well as a few additional verifications. Download them at www.sdmsoftware.com.

Step two: can occur in parallel with step one. In essence, step two suggests nothing more than back up your domain controllers! A domain upgrade is a one-directional action, so any problems will mean a very bad day if you don't have good backups. Remember that successfully grabbing your AD data will require a backup of every drive touched by AD. This is typically only the C drive, unless you've positioned your database or log files on other drives, as well as a System State Backup. For completeness, you might want to complete this task on every domain controller, although only a single domain controller backup is really necessary if you don't mind some extra work in the case of a failure.

Step three: starts after you're completely satisfied with your backups as well as the health of your not-yet-upgraded domain. This all-important step is usually considered the most challenging part of the upgrade—but not for technical reasons.

Before upgrading the OS on any domain controller, step three requires an upgrade to your forest and domain schemas. The challenge in this part of the upgrade is in proving that the schema upgrade's one-way only process won't completely destroy your AD. This is particularly the case if you've added any custom entries to your AD schema since the last OS-related upgrade, or if you use ADAM or Lightweight Directory Services partitions.

A schema upgrade is a task that can only be done once, so a smart way to test its functionality is by creating an offline copy of your AD within a virtual machine. Completing this task correctly requires a few steps of which you might not be aware because you don't want to create an orphaned domain controller object in your domain for your test virtual machine. To create an offline copy of your AD, use the following steps:

    * Create a new site in AD.
    * Add a member server virtual machine to the domain in the new site.
    * Run the DCPROMO wizard on that virtual machine to promote it to a domain controller.
    * Wait for replication to complete, then shut down the domain controller.
    * Create a copy of the virtual machine's disk file, then restart the domain controller.
    * Use the DCPROMO wizard to demote the domain controller back to a member server and remove it from the production network.
    * Once you complete the previous step, create a new virtual machine that uses the copy of the original virtual machine's disk file. Ensure that this second virtual machine has no connection to your production network (this is very important).
    * Power on the domain controller and seize each of the domain's FSMO roles.

Once these steps are complete, you have an exact copy of your AD that you can use to test a schema upgrade. If you experience any failures with the upgrade using this copy, you can use the offline virtual machine to determine the source of the failure.

You launch the schema upgrade with the adprep.exe tool, which can be found on the Windows Server 2008 R2DVD media in the supportadprep folder. There are two required uses of this tool, one to upgrade the forest and another to upgrade the domain. Two more optional switches can upgrade the schema for Read-Only Domain Controllers (if not completed during the 2003 to 2008 upgrade) and updating GPO permissions (for upgrades from Windows 2000). Each of the possible switch configurations is listed below. Remember to run the forest preparation before the domain preparation:
adprep.exe /forestprep
adprep.exe /domainprep
adprep.exe /domainprep /gpprep
adprep.exe /rodcprep

Step four: will likely involve the most work of all the steps. During this step, you will need to upgrade each and every domain controller in your domain, and eventually your forest. Obviously, this process involves upgrading the OS on each domain controller. It is usually a smart idea during this step to create a fresh installation of every domain controller rather than upgrade. Obviously, your first domain controller upgrade will need to be an in-place operation (to maintain your AD data); however, each subsequent upgrade can be a fresh installation.

Step five: doesn't occur until you've reached one of two milestones. At the point you've upgraded each of the domain controllers in your domain, only then can you upgrade your Domain Functional Level to Windows Server 2008 R2. Once every domain controller in the forest is upgraded, it becomes possible to upgrade the Forest Functional Level. Both of these actions can be accomplished within Active Directory Domains and Trusts on an upgraded domain controller. Each is a separate operation.


Your Mail works best with the New Yahoo Optimized IE8. Get it NOW!.