Monday, February 24, 2014

Filter Using Security Groups


Applies To: Windows 8, Windows Server 2008 R2, Windows Server 2012

To filter using security groups

  1. In the Group Policy Management Console (GPMC) console tree, expand Group Policy Objects and click the Group Policy object (GPO) to which you want to apply security filtering.
  2. In the results pane, on the Scope tab, click Add .
  3. In the Enter the object name to select box, type the name of the group, user, or computer that you want to add to the security filter. Click OK .

Additional considerations

  • In order to ensure that only members of the group or groups you added in Step 3 can receive the settings in this GPO, you will need to remove Authenticated Users if this group appears in the Scope tab. Click the Scope tab, select this group, and then click Remove .
  • You must have Edit settings, delete, and modify security permissions on the GPO to perform these procedures.
  • The settings in a GPO will apply only to users and computers that are contained in the domain, organizational unit, or organizational units to which the GPO is linked, and that are specified in or are members of a group that are specified in Security Filtering.

Additional references

Posted by at No comments:
Labels: ,

Folder Redirection Overview


Applies To: Windows 8, Windows Server 2008 R2, Windows Server 2012

Folder Redirection

User settings and user files are typically stored in the local user profile, under the Users folder. The files in local user profiles can be accessed only from the current computer, which makes it difficult for users who use more than one computer to work with their data and synchronize settings between multiple computers. Two technologies exist to address this problem: Roaming Profiles and Folder Redirection. Both technologies have their advantages, and they can be used separately or together to create a seamless user experience from one computer to another. They also provide additional options for administrators managing user data.
Folder Redirection lets administrators redirect the path of a folder to a new location. The location can be a folder on the local computer or a directory on a network file share. Users can work with documents on a server as if the documents were based on a local drive. The documents in the folder are available to the user from any computer on the network. Folder Redirection is located under Windows Settings in the console tree when you edit domain-based Group Policy by using the Group Policy Management Console (GPMC). The path is [Group Policy Object Name]\User Configuration\Policies\Windows Settings\Folder Redirection .

Recent changes to Folder Redirection

Folder Redirection now includes the following features:
  • The ability to redirect more folders in the user profile folders than in earlier Windows operating systems. This includes the Contacts , Downloads , Favorites , Links , Music , Saved Games , Searches , and Videos folders.
  • The ability to apply settings for redirected folders to Windows® 2000, Windows 2000 Server®, Windows XP, and Windows Server 2003 computers. You have the option to apply the settings that you configure on Windows Server® 2008 R2, Windows® 7, Windows Server 2008, or Windows Vista® only to computers that are running those operating systems, or to apply them to computers that are running earlier Windows operating systems also. For these earlier Windows operating systems, you can apply these settings to folders that can be redirected. These are the Application Data , Desktop , My Documents , My Pictures , and Start Menu folders. This option is available in the Settings tab in the Properties for the folder, under Select the redirection settings for [FolderName] .
  • The option to have the Music , Pictures , and Videos folders follow the Documents folder. In Windows operating systems earlier than Windows Vista, these folders were subfolders of the Documents folder. By configuring this option, you resolve any issues related to naming and folder structure differences between and earlier and more recent Windows operating systems. This option is available in the Target tab in the Properties for the folder, under Settings .
  • The ability to redirect the Start Menu folder to a specific path for all users. In Windows XP, the Start Menu folder could be redirected only to a shared target folder.
noteNote
This capability is new only to the Start Menu folder. All other redirectable folders in Windows Vista and later versions can also be redirected to a specific path for all users.

Folders that can be redirected

You can use the GPMC to redirect folders.

 

Folder in Windows 7 and Windows Vista Equivalent Folder in Earlier Windows Operating Systems
AppData/Roaming Application Data
Contacts Not Applicable
Desktop Desktop
Documents My Documents
Downloads Not Applicable
Favorites Not Applicable
Links Not Applicable
Music Not Applicable
Pictures My Pictures
Saved Games Not Applicable
Searches Not Applicable
Start Menu Start Menu
Videos Not Applicable

Advantages of Folder Redirection

  • Even if users log on to different computers on the network, their data is always available.
  • Offline File technology (which is turned on by default) gives users access to the folder even when they are not connected to the network. This is especially useful for people who use portable computers.
  • Data that is stored in a network folder can be backed up as part of routine system administration. This is safer because it requires no action by the user.
  • If you use Roaming User Profiles, you can use Folder Redirection to reduce the total size of your Roaming Profile and make the user logon and logoff process more efficient for the end-user. When you deploy Folder Redirection with Roaming User Profiles, the data synchronized with Folder Redirection is not part of the roaming profile and is synchronized in the background by using Offline Files after the user has logged on. Therefore, the user does not have to wait for this data to be synchronized when they log on or log off as is the case with Roaming User Profiles.
  • Data that is specific to a user can be redirected to a different hard disk on the user's local computer from the hard disk that holds the operating system files. This makes the user's data safer in case the operating system has to be reinstalled.
  • As an administrator, you can use Group Policy to set disk quotas, limiting how much space is taken up by user profile folders.

Selecting a Folder Redirection target

The Target tab of the folder's Properties box enables you to select the location of the redirected folder on a network or in the local user profile. You can choose between the following settings:
  • Basic—Redirect everyone's folder to the same location . This setting enables you to redirect everyone's folder to the same location and is applied to all users included in the Group Policy object (GPO). For this setting, you have the following options in specifying a target folder location:

    • Create a folder for each user under the root path . This option creates a folder in the form \\server\share\User Account Name\Folder Name . Each user has a unique path for their redirected folder.
noteNote
If you enable the Also apply redirection policy to Windows 2000, Windows 2000 Server, Windows XP, and Windows Server 2003 operating systems option on the Settings tab, this option is not available for the Start Menu folder.
  • Redirect to the following location . This option uses an explicit path for the redirection location. This can cause multiple users to share the same path for the redirected folder.
  • Redirect to the local user profile location . This option moves the location of the folder to the local user profile under the Users folder.
  • Advanced—Specify locations for various user groups . This setting enables you to specify redirection behavior for the folder based on the security group memberships for the GPO.
  • Follow the Documents folder . This option is available only for the Music , Pictures , and Videos folders. This option resolves any issues related to naming and folder structure differences between Windows 7 and Windows Vista, and earlier Windows operating systems. If you choose this option, you cannot configure any additional redirection options or policy removal options for these folders, and settings are inherited from the Documents folder.
noteNote
This behavior also occurs by default if you enable the Also apply redirection policy to Windows 2000, Windows 2000 Server, Windows XP, and Windows Server 2003 operating systems option on the Settings tab when you configure redirection settings for the Documents folder.
  • Not configured . This is the default setting. This setting specifies that policy-based folder redirection was removed for that GPO and the folders are redirected to the local user profile location or stay where they are based on the redirection options selected if any existing redirection policies were set. No changes are being made to the current location of this folder.

Configuring additional settings for the redirected folder

In the Settings tab in the Properties box for a folder, you can enable these settings:
  • Grant the user exclusive rights . This setting is enabled by default and is a recommended setting. This setting specifies that the administrator and other users do not have permissions to access this folder.
  • Move the contents of [FolderName] to the new location . This setting moves all the data the user has in the local folder to the shared folder on the network.
  • Also apply redirection policy to Windows 2000, Windows 2000 Server, Windows XP, and Windows Server 2003 operating systems . This enables folder redirection to work withWindows 7 and Windows Vista, and earlier Windows operating systems. This option applies only to redirectable folders in earlier Windows operating systems, which are the Application Data , Desktop , My Documents , My Pictures , and Start Menu folders.
noteNote
The AppData/Roaming (previously Application Data in earlier Windows operating systems) folder in Windows Vista now contains several folders that were previously under the root folder of the User Profile folder in earlier Windows operating systems. For example, in earlier Windows operating systems, the Start Menu folder was not under the Application Data folder. It might not make sense to redirect all the folders under Application Data when you enable the Also apply redirection policy to Windows 2000, Windows 2000 Server, Windows XP, and Windows Server 2003 operating systems setting. Therefore, if you choose this setting, Windows 7 and Windows Vista do not redirect the following folders automatically: Start Menu , Network Shortcuts , Printer Shortcuts , Templates , Cookies , Sent To . If you do not choose this setting, Windows 7 and Windows Vista automatically redirect all folders under the Application Data folder.

  • Policy Removal . The following table summarizes the behavior of redirected folders and their contents when the GPO no longer applies, based on your selections for policy removal. The following policy removal options are available in the Settings tab, under Policy Removal .

 

Policy Removal option Selected setting Result
Redirect the folder back to the user profile location when policy is removed Enabled
  • The folder returns to its user profile location.
  • The contents are copied, not moved, back to the user profile location.
  • The contents are not deleted from the redirected location.
  • The user continues to have access to the contents, but only on the local computer.
Redirect the folder back to the user profile location when policy is removed Disabled
  • The folder returns to its user profile location.
  • The contents are not copied or moved to the user profile location.
noteNote
If the contents of a folder are not copied to the user profile location, the user cannot see them.
Leave the folder in the new location when policy is removed Either Enabled or Disabled
  • The folder remains at its redirected location.
  • The contents remain at the redirected location.
  • The user continues to have access to the contents at the redirected folder.

Additional considerations

Posted by at No comments:
Labels:

Server Core Installation Option Getting Started Guide


Applies To: Windows Server 2008, Windows Server 2008 R2
This guide provides instructions for building a server that is based on the Server Core installation option of the Windows Server® 2008 or Windows Server® 2008 R2 operating systems. It includes information about installation, initial configuration, and managing a server that is running a Server Core installation.
What is a Server Core installation?
The Server Core installation option is an option that you can use for installing Windows Server 2008 or Windows Server 2008 R2. A Server Core installation provides a minimal environment for running specific server roles, which reduces the maintenance and management requirements and the attack surface for those server roles. A server running a Server Core installation of Windows Server 2008 supports the following server roles:
  • Active Directory Domain Services (AD DS)
  • Active Directory Lightweight Directory Services (AD LDS)
  • DHCP Server
  • DNS Server
  • File Services
  • Hyper-V
  • Print Services
  • Streaming Media Services
  • Web Server (IIS)
A server running a Server Core installation of Windows Server 2008 R2 supports the following server roles:
  • Active Directory Certificate Services
  • Active Directory Domain Services
  • Active Directory Lightweight Directory Services (AD LDS)
  • DHCP Server
  • DNS Server
  • File Services (including File Server Resource Manager)
  • Hyper-V
  • Print and Document Services
  • Streaming Media Services
  • Web Server (including a subset of ASP.NET)
To accomplish this, the Server Core installation option installs only the subset of the binary files that are required by the supported server roles. For example, the Explorer shell is not installed as part of a Server Core installation. Instead, the default user interface for a server running a Server Core installation is the command prompt.
Downloadable, printable job aids which include the most commonly used commands and procedures for administering Server Core installations are available at http://go.microsoft.com/fwlink/?LinkId=151984.
What’s new in the Server Core installation option?
The Server Core installation option of Windows Server 2008 or Windows Server 2008 R2 requires initial configuration at a command prompt. A Server Core installation does not include the traditional full graphical user interface. Once you have configured the server, you can manage it locally at a command prompt or remotely using a Terminal Server connection. You can also manage the server remotely using the Microsoft Management Console (MMC) or command-line tools that support remote use.
Server Core installations of Windows Server 2008 R2 support additional server roles (see the “What is a Server Core installation” section) and Windows features (see Installing Windows Features on a server running a Server Core installation of Windows Server 2008 R2: Overview).
In Server Core installations of Windows Server 2008 R2, the Removable Storage feature has been removed. You can also remotely manage a Server Core server using Server Manager.
Who should use this guide?
The target audience for the Server Core installation option of Windows Server 2008 and Windows Server 2008 R2 includes:
  • IT planners and analysts who are technically evaluating the product.
  • Enterprise IT planners and designers for organizations.
  • IT professionals who are managing any of the server roles supported in Server Core installations.
Benefits of a Server Core installation
The Server Core installation option of Windows Server 2008 or Windows Server 2008 R2 provides the following benefits:
  • Reduced maintenance. Because the Server Core installation option installs only what is required to have a manageable server for the supported roles, less maintenance is required than on a full installation of Windows Server 2008.
  • Reduced attack surface. Because Server Core installations are minimal, there are fewer applications running on the server, which decreases the attack surface.
  • Reduced management. Because fewer applications and services are installed on a server running the Server Core installation, there is less to manage.
  • Less disk space required. A Server Core installation requires only about 3.5 gigabytes (GB) of disk space to install and approximately 3 GB for operations after the installation.
In this guide
Posted by at No comments:
Labels:

Shadow Copies of Shared Folders


Shadow Copies of Shared Folders provides point-in-time copies of files that are located on shared resources, such as a file server. With Shadow Copies of Shared Folders, users can view shared files and folders as they existed at points of time in the past. Accessing previous versions of files, or shadow copies, is useful because users can:
  • Recover files that were accidentally deleted. If you accidentally delete a file, you can open a previous version and copy it to a safe location.
  • Recover from accidentally overwriting a file. If you accidentally overwrite a file, you can recover a previous version of the file. (The number of versions depends on how many snapshots you have created.)
  • Compare versions of a file while working. You can use previous versions when you want to check what has changed between versions of a file.

Additional considerations

  • When you restore a file, the file permissions will not be changed. Permissions will remain the same as they were before the file was restored. When you recover a file that was accidentally deleted, the file permissions will be set to the default permissions for the directory.
  • Shadow Copies of Shared Folders is available in all editions of Windows Server 2008 R2. However, the user interface is not available for the Server Core installation option. To create shadow copies for computers with a Server Core installation, you need to manage this feature remotely from another computer.
  • When you bring disks online, if a disk contains shadow copy storage space for a volume, it is brought online before the volume itself to prevent the possibility of lost snapshots.
  • Creating shadow copies is not a replacement for creating regular backups.
  • When storage area limits are reached, the oldest shadow copy will be deleted to make room for more shadow copies to be created. After a shadow copy is deleted, it cannot be retrieved.
  • Storage location, space allocation, and the schedule can be adjusted to suit your needs. On the Local Disk Properties page, on the Shadow Copies tab, click Settings.
  • There is a limit of 64 shadow copies per volume that can be stored. When this limit is reached, the oldest shadow copy will be deleted and cannot be retrieved.
  • Shadow copies are read-only. You cannot edit the contents of a shadow copy.
  • You can only enable Shadow Copies of Shared Folders on a per-volume basis—that is, you cannot select specific shared folders and files on a volume to be copied or not copied.

Additional references

For more information about Shadow Copies of Shared Folders and related backup and recovery features, see http://go.microsoft.com/fwlink/?LinkId=134698.
Posted by at No comments:
Labels:

Requirements and Recommendations for a Multi-Site Failover Cluster


Applies To: Windows Server 2008
This topic provides information about requirements and recommendations for a multi-site failover cluster. For a list of the steps for implementing a design for a multi-site cluster, see Checklist: Clustered Service or Application in a Multi-Site Failover Cluster (http://go.microsoft.com/fwlink/?LinkId=129126).
For additional information about designs for a multi-site cluster, see Design for a Clustered Service or Application in a Multi-Site Failover Cluster and Example, Clustered Service or Application in a Multi-Site Failover Cluster.
ImportantImportant
Multi-site failover clusters running Exchange Server 2007 use the Cluster Continuous Replication (CCR) feature of Microsoft Exchange Server 2007, and have a maximum of two nodes. For information about CCR and clustering, see the CCR topics at http://go.microsoft.com/fwlink/?Linkid=129111 and http://go.microsoft.com/fwlink/?Linkid=129112.
The following list provides information about requirements and recommendations for a multi-site cluster:
  • Hardware investment: A multi-site cluster requires an investment in redundant hardware, because it requires the additional servers and storage at the secondary site. Work closely with your hardware and software vendors to ensure that the solution you choose meets your requirements for server capacity, storage functionality, replication between sites, and network characteristics such as network latency.
  • Number of nodes and corresponding quorum configuration: For a multi-site cluster, we recommend having an even number of nodes and, for the quorum configuration, using the Node and File Share Majority option, that is, including a file share witness as part of the configuration. This is shown in the diagram in Design for a Clustered Service or Application in a Multi-Site Failover Cluster. The file share witness can be located at a third site, that is, a different location from the main site and secondary site, so that it is not lost if one of the other two sites has problems.

    Any cluster with an even number of nodes should use a quorum configuration that includes a witness (disk witness or file-share witness) as a tie-breaker. For the witness for a multi-site cluster, we recommend a file share witness, not a disk witness, because it is easier to keep the file share witness accessible to both sites.

    ImportantImportant
    See the important note at the beginning of this topic about multi-site failover clusters running Exchange Server 2007.
    It is also possible to design a multi-site cluster that has an odd number of nodes (except as previously noted for Exchange Server 2007), with the majority of nodes at the main site. This design should use the Node Majority quorum configuration (as should all configurations with an odd number of nodes). Note that with this design, complete failure of the main site requires you to intervene and force the cluster to start at the secondary site, because the secondary site has only a minority of nodes. Forcing the cluster to start in this way is called forcing quorum.

    For additional information about quorum configurations, see Appendix F: Reviewing Quorum Configuration Options for a Failover Cluster.
  • Network configuration—deciding between multi-subnets and a VLAN: A multi-site cluster running Windows Server 2008 can contain nodes that are in different subnets, unless it is a cluster running SQL Server 2005 or SQL Server 2008 (which requires the use of a virtual local area network or VLAN). In other words, the cluster nodes can potentially communicate across network routers. However, when using multiple subnets, it is important to consider how clients will discover services or applications that have just failed over.

    Although a clustered service or application keeps the same network name after failover, if it fails over to a server in a different subnet, that network name will then be associated with a new IP address. The DNS servers must update one another with this new IP address before clients can discover the service or application that has failed over. In addition, on the client, the cached DNS entries need to expire before the client queries a DNS server again. In other words, with multiple subnets, the amount of downtime that clients experience is dependent not just on how quickly failover occurs, but also on how quickly DNS replication occurs and how quickly the clients query for updated DNS information.

    To minimize downtime in a multi-site cluster, consider the following approaches:

    • Review your options for using VLANs and for using multiple subnets to connect the nodes. Each approach has its advantages (but note that a cluster running SQL Server 2008 must be configured with a VLAN). One of the advantages for VLANs is that they avoid issues associated with the time it takes for DNS replication to complete. However, multiple subnets can be simpler than VLANs to set up and manage.
    • If you prefer to use multiple subnets in your multi-site cluster, you might choose to modify two private properties associated with the network name resources in your cluster. One property is the Time to Live (TTL) property, which can limit the amount of time that a given DNS record is used before it will be discarded, that is, limit the persistence of DNS information that might be stale because a failover occurred. The default Time to Live is 20 minutes or 1200 seconds, but you can limit it according to recommendations for your application. (For example, the recommended value for Exchange Server 2007 is 5 minutes or 300 seconds.) For more information, see http://go.microsoft.com/fwlink/?LinkId=128166 and http://go.microsoft.com/fwlink/?LinkId=130588.

      The other private property that you might choose to modify controls which IP addresses are registered in DNS: either all IP addresses on which a network name resource depends, or only the IP address that successfully comes online (that is, the IP address on the subnet of the node that currently owns that network name resource). If you register all IP addresses on which a network name resource depends, any IP address that is needed by a network name will always be registered (regardless of subnet), minimizing downtime. This private property is most useful when the client side of your client-server application is capable of handling DNS records with multiple IP addresses associated with the network name. For more information, see http://go.microsoft.com/fwlink/?LinkId=130588.
  • Network configuration—Hyper-V, DHCP, and static IP addresses: In a multi-site cluster where the nodes run Hyper-V and use multiple subnets, if the virtual machines use DHCP rather than static IP addresses, failover is fully automatic even when the new owner node is in a different subnet than the old. However, if the virtual machines use static IP addresses, when failover occurs to a node in a different subnet, you must adjust the IP addresses manually to an appropriate address.
  • Tuning of heartbeat settings: In a multi-site cluster, you might want to tune the "heartbeat" settings. The heartbeat settings include the frequency at which the nodes send heartbeat signals to each other to indicate that they are still functioning, and the number of heartbeats that a node can miss before another node initiates failover and begins taking over the services and applications that had been running on the failed node. You can tune these settings for heartbeat signals to account for differences in network latency caused by communication across subnets. For information about how to tune heartbeat settings, see http://go.microsoft.com/fwlink/?LinkId=130588.
  • Replication of data: Replication of data between sites is very important in a multi-site cluster, and is accomplished in different ways by different hardware vendors. Therefore, the choice of the replication process requires careful consideration. When making this choice, consult with your hardware and software vendors, and review the following considerations:

    • Choosing replication level: block, file system, or application level: The replication process can function through the hardware (at the block level), through the operating system (at the file system level), or through certain applications such as Microsoft Exchange Server 2007 (which has a feature called Cluster Continuous Replication or CCR). Work with your hardware and software vendors to choose a replication process that fits the requirements of your organization.
    • Configuring replication to avoid data corruption: The replication process must be configured so that any interruptions to the process will not result in data corruption, but instead will always provide a set of data that matches the data from the main site as it existed at some moment in time. In other words, the replication must always preserve the order of I/O operations that occurred at the main site. This is crucial, because very few applications can recover if the data is corrupted during replication.
    • Not using Distributed File System Replication: You cannot use the feature in Windows Server 2008 called Distributed File System Replication (DFS-R) as your data replication method in a multi-site cluster. DFS-R only performs its data replication after a file is closed. This works well for files such as documents, presentations, or spreadsheets, but it will not work for files that are held open, such as databases or virtual machines. You must choose a replication option other than DFS-R.
    • Choosing between synchronous and asynchronous replication: The replication process can be synchronous, where no write operation finishes until the corresponding data is committed at the secondary site, or asynchronous, where the write operation can finish at the main site and then be replicated (as a background operation) to the secondary site. Synchronous replication means that the replicated data is always up-to-date, but it slows application performance while each operation waits for replication. Asynchronous replication can help maximize application performance, but if failover to the secondary site is necessary, some of the most recent user operations might not be reflected in the data after failover. This is because some operations that were finished recently might not yet be replicated.

      Synchronous replication is best for multi-site clusters that can are using high-bandwidth, low-latency connections. Typically, this means that a cluster using synchronous replication must not be stretched over a great distance. Asynchronous replication is best for clusters where you want to stretch the cluster over greater geographical distances with no significant application performance impact.
For diagrams showing basic designs for a multi-site cluster, see Design for a Clustered Service or Application in a Multi-Site Failover Cluster and Example, Clustered Service or Application in a Multi-Site Failover Cluster.
Posted by at No comments:
Labels:

Saturday, February 22, 2014

Convert Windows Server 2008 to Workstation


 1. Installation, Drivers, OS Language and Owner Information: Installation of Microsoft Windows Server 2008 and how to set owner name and -organization.
2. Wireless Networking: (If you don’t use wireless, skip this step) Enable wireless networking in Windows Server 2008.
3. New User, Auto Logon and Strong Passwords Enforcement: How to create a new user, how to configure a user to logon automatically and how to disable enforcement of a minimum complexity for passwords.
4. Shutdown Tracker: How to disable the annoying Shutdown Event Tracker.
5. Ctrl+Alt+Del: Disable ctrl+alt+del at Windows startup.
6. Audio and Startup Sound: Enable audio and Startup Sound in Windows Server 2008.
7. Computername: Change computername.
8. Performance: Increase performance of applications in windows server.
9. Internet Explorer Enhanced Security: Disable Enhanced Security in Internet Explorer.
10. Themes, SideBar with Custom Gadgets, Aero Cursors and Thumbnails: Enable the Vista Aero theme and 3d flip with Sidebar and preview thumbnails in Windows Explorer.
11. SuperFetch: Maintain and Improve your system performance.
12. Delay Activation: How to extend the evaluation period to 240 days.

More Features

13. Windows Search: Install the Windows Search service to search your Outlook and documents.
14. Hyper-V: How to install the Hyper-V virtualization serverrole in Windows Server 2008 x64.
15. Offline Files: Installing the Offline Files feature to improve mobility!

Additional Information

Forum: Place here all your questions, problems and solutions about configuring and using Windows Server 2008 as Workstation.
Security Software: Check what Antivirus and Firewall programs are compatible with Windows Server 2008.
Games and Entertainment: List of Games that can (not) be played and articles about how to get them working.
Wish List: Features we want to have in Windows Server 2008, but aren’t working yet.
Fine-Tuning Services: Optimize performance by configuring the Windows Services.
Youtube Channel: Tips & Tricks from the win2008workstation Youtube Channel.

Other Posts: Missing gameux.dll, Missing xinput9_1_0.dll, Disabling DEP, Patching .msi installers, Game Controllers, Install GTA2, Win2008Workstation Converter, Take Ownership/Permissions, Custom Logonscreen Background
Useful forum Topics: TV Tuner in Server 2008, Applications Compatibility (x86) (x64), Windows Live Applications, Skype, Windows Movie Maker, Snipping Tool, Vista Games.
External links: Installing Microsoft Bluetooth Stack (x86/x64), Students get Windows Server 2008 for free via DreamSpark!

Posted by at No comments:
Labels: ,

Password Settings objects (PSOs)


Step 1: Create a PSO

35 out of 43 rated this helpful - Rate this topic
Updated: July 14, 2010
Applies To: Windows Server 2008, Windows Server 2008 R2
Creating a PSO
You can create Password Settings objects (PSOs):
Creating a PSO using the Active Directory module for Windows PowerShell
To create a PSO (fine-grained password policy) using the Active Directory module for Windows PowerShell see, Create a New Fine-Grained Password Policy.
Creating a PSO using ADSI Edit
Active Directory Service Interfaces Editor (ADSI Edit) provides a view of every object and attribute in an Active Directory Domain Services (AD DS) forest. You can use ADSI Edit to query, view, and edit AD DS objects and attributes.
Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
To create a PSO using ADSI Edit
  1. Click Start, click Run, type adsiedit.msc, and then click OK.
    noteNote
    If you are running ADSI Edit for the first time on a domain controller, proceed to step 2. Otherwise, proceed to step 4.
  2. In the ADSI Edit snap-in, right-click ADSI Edit, and then click Connect to.
  3. In Name, type the fully qualified domain name (FQDN) of the domain in which you want to create the PSO, and then click OK.
  4. Double-click the domain.
  5. Double-click DC=.
  6. Double-click CN=System.
  7. Click CN=Password Settings Container.
    All the PSO objects that have been created in the selected domain appear.
  8. Right-click CN=Password Settings Container, click New, and then click Object.
  9. In the Create Object dialog box, under Select a class, click msDS-PasswordSettings, and then click Next.
  10. In Value, type the name of the new PSO, and then click Next.
  11. Continue with the wizard, and enter appropriate values for all mustHave attributes.
    ImportantImportant
    To disable account lockout policies, assign the msDS-LockoutThreshold attribute the value of 0.
    noteNote
    To avoid ADSI Edit errors, values for the four time-related PSO attributes (msDS-MaximumPasswordAge, msDS-MinimumPasswordAge, msDS-LockoutObservationWindow, and msDS-LockoutDuration) must be entered in the d:hh:mm:ss format (recommended) or the I8 format. Note that the d:hh:mm:ss format is only available in the Windows Server 2008 version of ADSI Edit. For more information about how to convert time unit values into I8 values, see "Negative PSO Attribute Values" in Appendix B: PSO Attribute Constraints.
    noteNote
    For more information about time-related PSO attributes, see "PSO Attributes Referential Integrity" in Appendix B: PSO Attribute Constraints.

     

    Attribute name Description Acceptable value range Example value
    msDS-PasswordSettingsPrecedence Password Settings PrecedenceGreater than 010
    msDS-PasswordReversibleEncryptionEnabled Password reversible encryption status for user accountsFALSE / TRUE (Recommended: FALSE)FALSE
    msDS-PasswordHistoryLength Password History Length for user accounts0 through 102424
    msDS-PasswordComplexityEnabled Password complexity status for user accountsFALSE / TRUE (Recommended: TRUE)TRUE
    msDS-MinimumPasswordLength Minimum Password Length for user accounts0 through 2558
    msDS-MinimumPasswordAge Minimum Password Age for user accounts
    • (None)
    • 00:00:00:00 through msDS-MaximumPasswordAge value
    		1:00:00:00 (1 day)
    msDS-MaximumPasswordAge Maximum Password Age for user accounts
    • (Never)

      To set the time to (never), set the value to -9223372036854775808.
    • msDS-MinimumPasswordAge value through (Never)
    • msDS-MaximumPasswordAge cannot be set to zero
    		42:00:00:00 (42 days)
    msDS-LockoutThreshold Lockout threshold for lockout of user accounts0 through 6553510
    msDS-LockoutObservationWindow Observation Window for lockout of user accounts
    • (None)
    • 00:00:00:01 through msDS-LockoutDuration value
    		0:00:30:00 (30 minutes)
    msDS-LockoutDuration Lockout duration for locked out user accounts
    • (None)
    • (Never)
    • msDS-LockoutObservationWindow value through (Never)
    		0:00:30:00 (30 minutes)
    msDS-PSOAppliesTo Links to objects that this password settings object applies to (forward link)0 or more DNs of users or global security groups“CN=u1,CN=Users,DC=DC1,DC=contoso,DC=com”
    noteNote
    To create a PSO without applying it to any users or global security groups, proceed to step 17. Otherwise, proceed to step 12.
  12. On the last screen of the wizard, click More Attributes.
  13. On the Select which property to view menu, click Optional or Both.
  14. In the Select a property to view drop-down list, select msDS-PSOAppliesTo.
  15. In Edit Attribute, add the distinguished names of users or global security groups that the PSO is to be applied to, and then click Add.
  16. Repeat step 15 to apply the PSO to more users or global security groups.
  17. Click Finish.
    noteNote
    If you receive this error:
    Operation failed. Error code: 0x57
    The parameter is incorrect.
    Check the syntax of the distinguished name of the account. The following characters in the distinguished name need to be escaped with a backslash:
    , \ # + < > ; " =
    For example, cn=Smith\, John,ou=West,dc=contoso,dc=com
Creating a PSO using ldifde
You can use the ldifde command as a scriptable alternative for creating PSOs.
LDAP Data Interchange Format (LDIF) is an Internet standard for a file format that you can use to perform batch operations against directories that conform to Lightweight Directory Access Protocol (LDAP) standards. You can use LDIF to export and import data. LDIF performs batch operations such as add, create, and modify against AD DS. When you install the AD DS role, a utility program called LDIFDE is included to support batch operations that are based on the LDIF file standard. For more information, see Using LDIFDE to import and export directory objects to Active Directory (http://go.microsoft.com/fwlink/?LinkId=87487).
Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
To create a PSO using ldifde
  1. Define the settings of a new PSO by saving the following sample code as a file, for example, pso.ldf:
    Copy
    dn: CN=PSO1, CN=Password Settings Container,CN=System,DC=dc1,DC=contoso,DC=com
changetype: add
objectClass: msDS-PasswordSettings
msDS-MaximumPasswordAge:-1728000000000
msDS-MinimumPasswordAge:-864000000000
msDS-MinimumPasswordLength:8
msDS-PasswordHistoryLength:24
msDS-PasswordComplexityEnabled:TRUE
msDS-PasswordReversibleEncryptionEnabled:FALSE
msDS-LockoutObservationWindow:-18000000000
msDS-LockoutDuration:-18000000000
msDS-LockoutThreshold:0
msDS-PasswordSettingsPrecedence:20
msDS-PSOAppliesTo:CN=user1,CN=Users,DC=dc1,DC=contoso,DC=com
    noteNote
    When you use ldifde to create PSOs, values for the four time-related PSO attributes (msDS-MaximumPasswordAge, msDS-MinimumPasswordAge, msDS-LockoutObservationWindow, and msDS-LockoutDuration) must be entered in the I8 format. For more information about how to convert time unit values into I8 values, see "Negative PSO Attribute Values" in Appendix B: PSO Attribute Constraints.
    noteNote
    For more information about time-related PSO attributes, see "PSO Attributes Referential Integrity" in Appendix B: PSO Attribute Constraints.
  2. Open a command prompt. To open a command prompt, click Start, click Run, type cmd, and then click OK.
  3. Type the following command, and then press ENTER:
    Copy
    ldifde –i –f pso.ldf

 

Parameter Description
ldifdeSpecifies a utility program that supports batch operations that are based on the LDIF file standard.
-iSpecifies that Import Mode is turned on.
-f pso.ldfSpecifies the name of the input file that you created.
Posted by at No comments:
Labels:
Subscribe to: Posts (Atom)