Good Morning all. I'm on my OpenSuse journey and learning alot about the OS. This is a quick tutorial on how to enable and access ssh using the following steps.
1. The ssh daemon comes disabled by default. Ssh can be enabled by typing the following command. /etc/init.d/sshd
2. The next step is to add the ssh service to the opensuse firewall you can use the following two methods.
method 1: type: yast firewall method 2: you can directly edit the /etc/sysconfig/SuSEfirewall2 text file using either vi or emacs i prefer using vi. :)
3. In the /etc/sysconfig/SuSEfirewall2 text file edit the following: FW_SERVICES_EXT_TCP="" and replace it with FW_SERVICES_EXT_TCP="ssh"
4. restart the firewall with the following command: /sbin/rcSuSEfirewall2 restart
This is a quick tutorial on how to recover the root password on opensuse.
1. Boot the system and select the normal boot menu from the list. Once selected, in the "Boot Options" box type the following.
"init=/bin/bash" if you are using GRUB Boot loader
or
"linux init=/bin/bash" if you are using LILO Boot Loader
This will launch you straight into a Bash shell prompt which comes up even before the Single User mode loads and has the "/" root file system mounted.
2. Do a mount command to check if the root file system "/" is mounted as Read-Write. If root is not mounted as Read-Write, then run the following command:
mount -o remount,rw /
3. Now, simply type the passwd command and enter a new password
4. Reboot the system and log into the box with your new root password.
This is just a quick tutorial on how to add users from the command line in snow leopard. This command will also work in previous versions of os x. The following commands need to be run as root or with the sudo command.
Creating a new user
dscl / -create /Users/bsdjedi
Create a new user and set the default shell for that user
dscl / -create /Users/bsdjedi UserShell /bin/ksh
Creating a new user and setting the uid as well
dscl / -create /Users/bsdjedi UniqueID 800
Setting the password when creating a user
dscl / -create /Users/bsdjedi PASSWORD
or you can use the tradition unix way and run the following:
passwd bsdjedi
If you would like to give a user admin right run the following command
7-Zip - compression program IZArc - compression program TugZIP - compression program CabPack - compression program Universal Extractor - extract files from any type of archive
FileZilla - FTP client FileZilla Server - FTP server EFTP - FTP client/server XAMPP - integrated server package of Apache, mySQL, PHP and Perl WAMP - Apache, PHP5 and MySQL server
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
Drag an item's icon to the Trash (in the Dock), or select the item and press Command-Delete.
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:
Click the Trash icon in the dock.
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.
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.
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 there are several locked files in the Trash, you can unlock them all at the same time at the command line. Follow these steps:
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.
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.
Press the Command-A key combination to select all files in the Trash.
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.
Press Return. No special text message will be shown indicating that the command was successful.
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 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.
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.
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.
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.
