Through the Policy and Automation Management node, you can access Microsoft Exchange and home directory policies, as well as built-in and custom policies. Use the following common tasks to improve your enterprise security and data integrity.
Enables you to define Microsoft Exchange configuration, mailbox policy, automatic naming, and proxy generation rules. These rules can define how mailboxes are managed when an assistant administrator creates, modifies, or deletes a user account.
Enables you to automatically create, rename, or delete home directories and home shares when an assistant administrator creates, renames, or deletes a user account. Home directory policy also allows you to enable or disable disk quota support for home directories on Microsoft Windows servers as well as on non-Windows servers.
Enables you to define the requirements for passwords generated by DRA.
For more detailed information about managing policies in DRA, reference the following sections:
Exchange provides several policies to help you more effectively manage Microsoft Exchange objects. Microsoft Exchange policy allows you to automate mailbox management, enforce naming conventions for aliases and mailbox stores, and automatically generate email addresses.
These policies can help you streamline your workflows and maintain data integrity. For example, you can specify how Exchange manages mailboxes when you create, modify, or delete user accounts. To define and manage Microsoft Exchange policies, you must have the appropriate powers, such as those included in the built-in Manage Policies and Automation Triggers role.
To specify default email address policy, you must have the appropriate powers, such as those included in the built-in Manage Policies and Automation Triggers role, and your license must support the Exchange product.
To specify a default email address policy:
Navigate to Policy and Automation Management > Configure Exchange Policies > Proxy Generation.
Specify the domain of the Microsoft Exchange server.
Click Browse.
Specify additional search criteria as needed, and then click Find Now.
Select the domain to configure, and then click OK.
Specify the proxy generation rules for the selected domain.
Click Add.
Select a proxy type. For example, click Internet Address.
Accept the default value or type a new proxy generation rule, and then click OK.
For more information about supported substitution strings for proxy generation rules, see Delegation and Configuration Client Policy
Click Custom attributes to edit the custom name of custom mailbox properties.
Select the attribute and click the Edit button.
In the Attribute Properties window, enter the attribute name in the Custom name field, and click OK.
Click OK.
NOTE:DRA Policy Admins should have the Manage Custom Tools power to modify custom attributes in the Microsoft Exchange policy.
Mailbox rules let you specify how Exchange manages mailboxes when assistant administrators create, clone, modify, or delete user accounts. Mailbox rules automatically manage Microsoft Exchange mailboxes based on how the assistant administrator manages the associated user accounts.
NOTE:When enabling the Do not allow Assistant Admins to create a user account without a mailbox option in Microsoft Windows domains, ensure the assistant administrator has power to either clone or create a user account. Enabling this option requires assistant administrators to create Windows user accounts with a mailbox.
To specify Microsoft Exchange mailbox rules, you must have the appropriate powers, such as those included in the built-in Manage Policies and Automation Triggers role, and your license must support the Exchange product.
To specify Exchange mailbox rules:
Navigate to Policy and Automation Management > Configure Exchange Policies > Mailbox Rules.
Select the mailbox policies you want Exchange to enforce when you create or modify user accounts.
Click OK.
To specify Office 365 license policies, you must have the appropriate powers, such as those included in the built-in Manage Policies and Automation Triggers role. Your license must also support the Microsoft Exchange product.
If you want to allow DRA to manage your Office 365 licenses, you must do the following:
Create a license enforcement policy.
Enable the License update schedule on the tenant properties page.
To create a policy to enforce Office 365 licenses, click the Policy and Automation Management node in the Delegation and Configuration console, and select New Policy > Create New Policy to Enforce Office 365 Licenses.
When the policy is enforced and a user is added to Active Directory, DRA uses group membership to automatically assign the Office 365 license to the user.
Policies that you create to enforce Office 365 licenses are not applied when changes are made outside of DRA unless you also enable the License update schedule on the tenant properties page. The license update job ensures that the Office 365 licenses assigned to users match your Office 365 license policies.
The license update job and Office 365 license policies work together to ensure that all of your managed users are assigned only the Office 365 licenses they are supposed to have.
NOTE:
DRA does not manage Office 365 licenses for online-only user accounts. In order for DRA to manage your users with Office 365 licenses, those users must be synced with Active Directory.
If you choose to use DRA to manage your Office 365 licenses, DRA will override any manual changes to Office 365 licenses made outside of DRA the next time the license update job runs.
If you enable the Office 365 license update job before ensuring that your Office 365 license policies are configured properly, your assigned licenses might be incorrect after the license update job runs.
When you manage a large number of user accounts, creating and maintaining these home directories and shares can require a lot of time and can be a source of security errors. Additional maintenance can be required each time a user is created, renamed, or deleted. Home directory policies help you manage home directory and home share maintenance.
DRA allows you to automate the creation and maintenance of user home directories. For example, you can easily configure DRA so that the Administration server creates a home directory when you create a user account. In this case, if you specify a home directory path when you create the user account, the server automatically creates the home directory per the specified path. If you do not specify a path, the server does not create the home directory.
DRA supports Distributed File System (DFS) paths during creation of user home directories or configuration of home directory policies for users in allowable parent paths. You can create, rename, and delete home directories on Netapp Filers and DFS paths or partitions.
To configure home directory, share, and volume disk quota policies, you must have the appropriate powers, such as those included in the built-in Manage Policies and Automation Triggers role. Each policy automatically manages home directories, share, and volume disk quota based on how you manage the associated user accounts.
To configure home directory policies, navigate to Policy and Automation Management > Configure Home Directory Policies >
Home directory
Home share
Home Volume Disk Quota
For each computer where you need to create a home share, the Administration server service account or access account should be an administrator on that computer or a member of the Administrators group in the corresponding domain.
An administration share, such as C$ or D$, must exist for each drive on which DRA manages and stores home directories. DRA uses the administration shares to perform some home directory and home share automation tasks. If these shares do not exist, DRA cannot provide home directory and home share automation.
To configure the Allowable Parent Paths for a NetApp Filer:
Navigate to Policy and Automation Management > Configure Home Directory Policies.
In the Allowable parent paths text box, enter one of the allowable paths from the following table:
|
Share type |
Allowable path |
|---|---|
|
Windows |
(\\FileName\adminshare:\volumerootpath\directorypath) |
|
Non-Windows |
(\\non-windows\share) |
Click Add.
Repeat Steps 1-3 for each allowable parent path wherever you want to apply the home directory policies.
To be consistent with proper Microsoft Windows security policies, DRA creates access control restrictions at the directory level only. Placing access control restrictions at both the share name level and the file or directory object level often leads to a confusing access scheme for administrators and users.
When you change an access control restriction for a home share, DRA does not change the existing security for that directory. In this case, you must ensure that the user accounts have the appropriate access to their own home directories.
DRA automates home directory maintenance tasks by managing home directories when you modify a user account. DRA can perform different actions when a user account is created, cloned, modified, renamed, or deleted.
To successfully implement your home directory policy, consider the following guidelines:
Ensure the specified path uses the correct format.
To specify a path for a single home directory, use one of the templates from the following table:
|
Share Type |
Path Template |
|---|---|
|
Windows |
\\computer\share\. For example, if you want DRA to automatically create a home directory in the Home Share folder on the server01 computer, type \\server01\Home Share\ |
|
Non-Windows |
\\non-windows\share |
To standardize home directory administration on the root directory of the corresponding home share, use the Universal Naming Convention syntax, such as \\server name\C:\path to root directory.
To specify a path for nested home directories, use one of the templates from the following table:
|
Share Type |
Path Template |
|---|---|
|
Windows |
\\computer\share\first directory\second directory\ For example, if you want DRA to automatically create a home directory in the existing JSmith\Home directory under the Home Share folder on the server01 computer, type \\server01\Home Share\JSmith\Home. |
|
Non-Windows |
\\non-windows\share\first directory\second directory\ |
NOTE:DRA also supports the following formats: \\computer\share\usernameand \\computer\share\%username%. In each case, DRA automatically creates a home directory for the associated user account.
When you define a policy or automation trigger for managing home directories on a NetApp filer, you need to use a different format for the directory specification.
If you are using NetApp filers, specify the parent directory in the following format: \\FilerName\adminshare:\volumerootpath\directorypath
The adminshare variable is the hidden share that maps to the root volume on the NetApp filer, such as c$. For example, if the local path of the share on a NetApp filer, called usfiler, is c$\vol\vol0\mydirectory, you can specify a root path of \\usfiler\c:\vol\vol0\mydirectory for the NetApp filer.
To specify a DFS path while you create user home directories or configure home directory policies for users, use \\server\root\<link> format, where root can be either the managed domain or a standalone root directory in the following format: \\FilerName\adminshare:\volumerootpath\directorypath.
Create a shared directory to store the home directory for this user account.
Ensure that DRA can access the computer or share referenced in the path.
This rule allows DRA to automatically create home directories for new user accounts. When DRA creates a home directory, the Administration server uses the path specified in the Home directory fields in the Create User Wizard. You can later modify this path through the Profile tab of the user properties window and DRA will move the home directory to the new location. If you do not specify values for these fields, DRA does not create a home directory for that user account.
DRA sets the security for the new directory based on the selected Home directory permissions options. These options let you control the general access for all home directories.
For example, you can specify that members of the Administrators group have full control and members of the Help Desk group have read access to the share in which the user home directories are created. Then, when DRA creates a user home directory, the new home directory can inherit these rights from the parent directory. Therefore, members of the Administrators group have Full Control over all user home directories and members of the Help Desk group have read access to all user home directories.
If the specified home directory already exists, DRA does not create the home directory and does not modify the existing directory permissions.
This rule allows DRA to automatically perform the following actions:
Create a home directory when you specify a new home directory path
Move home directory contents when you change the home directory path
Rename a home directory when you rename the user account
When you rename a user account, DRA renames the existing home directory based on the new account name. If the existing home directory is currently in use, DRA creates a new home directory with the new name and does not change the existing home directory.
When you change the home directory path, DRA attempts to create the specified home directory and move the contents of the previous home directory to the new location. You can also configure the Home Directory policy to create a home directory without moving the contents from the existing home directory. DRA also applies the assigned ACLs from the previous directory to the new directory. If the specified home directory already exists, DRA does not create this new directory and does not modify the existing directory permissions. If the previous home directory is not locked, DRA deletes it.
When DRA fails to rename the home directory, DRA tries to create a new home directory with a new name and copy the contents from the previous home directory to the new home directory. DRA then attempts to delete the previous home directory. You can configure DRA not to copy the contents from the previous home directory to the new home directory and manually move the contents from the previous home directory to the new home directory to avoid concerns such as copying open files.
While deleting the previous home directory, DRA requires explicit permission to delete read-only files and subdirectories from the previous home directory. You can provide DRA the permission to explicitly delete the read-only files and subdirectories from the previous home directory.
DRA allows you to specify the allowable parent directories or paths for home shares on file servers. If you have many directory or file server paths to specify, you can export these paths to a CSV file and add the paths from the CSV file to DRA using the DRA console. DRA uses the information entered in the Allowable parent paths field to ensure:
DRA does not delete the parent directory on the file server when assistant administrators delete a user account and the user account home directory.
DRA moves the home directory to a valid parent directory or path on the file server when you rename a user account or change the home directory path for a user account.
This rule allows DRA to automatically delete a home directory when you delete the associated user account. If you enable the Recycle Bin, DRA does not delete the home directory until you delete the user account from the Recycle Bin. While deleting the home directory, DRA requires explicit permission to delete read-only files and subdirectories from the previous home directory. You can provide DRA the permission to explicitly delete the read-only files and subdirectories from the previous home directory.
DRA automates home share maintenance tasks by managing home shares when you modify a user account or manage home directories. DRA can perform different actions when a user account is created, cloned, modified, renamed, or deleted.
To be consistent with proper Microsoft Windows security policies, DRA does not create access control restrictions at the share name level. Instead, DRA creates access control restrictions at the directory level only. Placing access control restrictions at both the share name level and the file or directory object level often leads to a confusing access scheme for administrators and users.
NOTE:The specified location must have a common home share, such as HOMEDIRS, at one level above the home directories.
For example, the following path is valid: \\HOUSERV1\HOMEDIRS\%username%
The following path is invalid: \\HOUSERV1\%username%
When defining the home share automation rules, you can specify a prefix and suffix for each automatically created home share. By specifying a prefix or suffix, you can enforce a naming convention for home shares.
For example, you enable the Create home directory and Create home share automation rules. For the home share, you specify an underscore prefix and a dollar sign suffix. When you create a user named TomS, you map his new directory to the U drive and specify \\HOUSERV1\HOMEDIRS\%username% as the directory path. In this example, DRA creates a network share named _TomS$ that points to the \\HOUSERV1\HOMEDIRS\TomS directory.
When DRA creates a home share, the Administration server uses the path specified in the Home directory fields in the Create User Wizard. You can later modify this path through the Profile tab of the user properties window.
DRA creates the share name by adding the specified prefix and suffix, if any, to the user name. If you use long user account names, DRA may not be able to add the specified home share prefix and suffix. The prefix and suffix, as well as the number of permitted connections, are based on the home share creation options you select.
If the home share name generated from the newly created user account name already exists, DRA deletes the existing share and create a new share to the specified home directory.
When cloning a user account, the share name of the existing user account must currently exist. When you clone a user account, DRA also clones the home directory information and customizes that information for the new user.
When you change the home directory location, DRA deletes the existing share and creates a new share to the new home directory. If the original home directory is empty, DRA deletes the original directory.
When you rename a user account, DRA deletes the existing home share and creates a new share based on the new account name. The new share points to the existing home directory.
When you permanently delete a user account, DRA deletes the home share.
DRA allows you to manage disk quotas for home volumes. You can implement this policy in native domains where the home directory resides on a Microsoft Windows computer. When you implement this policy, you should specify a disk quota of at least 25MB, to allow for ample room.
This feature enables you to specify the policy settings for passwords that DRA generates. DRA does not enforce these settings on passwords that users create. When configuring Password Policy properties the password length must be no less than 6 characters and no more than 127 characters, all the values can be set to zero except for the password length and maximum limit.
To configure Password Generation Policies, navigate to Policy and Automation Management > Configure Password Generation Policies, and select the Enable Password Policy check box. Click Password Settings and configure the Password Policy properties.
To delete, enable, or disable policies, you must have the appropriate powers, such as those included in the built-in Manage Policies and Automation Triggers role.
To perform one of these actions, navigate to Policy and Automation Management > Policy. Right-click the policy that you want to delete, enable, or disable in the right pane, and select the desired action.
To implement built-in policies, you must have the appropriate powers, such as those included in the built-in Manage Policies and Automation Triggers role. For more information about built-in policies, see Understanding Built-in Policies.
NOTE:Before associating the built-in policy with an assistant administrator and an ActiveView, first verify that the assistant administrator is assigned to that ActiveView.
To implement built-in policies:
Navigate to Policy and Automation Management > Policy.
On the Tasks menu, click New Policy, and then select the type of built-in policy you want to create.
On each wizard window, specify the appropriate values, and then click Next. For example, you can associate this new policy with a specific ActiveView, allowing DRA to enforce this policy on objects included by that ActiveView.
Review the summary, and then click Finish.
To implement a custom policy, you must have the appropriate powers, such as those included in the built-in Manage Policies and Automation Triggers role.
To successfully implement a custom policy, you must write a script that runs during a specific operation (administrative task). In the custom policy script, you can define error messages to display whenever an action violates the policy. You can also specify a default error message through the Create Policy Wizard.
For more information about writing custom policies, viewing a list of Administration operations, or using argument arrays, see the SDK. For more information, see Writing Custom Policy Scripts or Executables.
NOTE:
Before associating the custom policy with an assistant administrator and an ActiveView, first ensure that the assistant administrator is assigned to that ActiveView.
If the path of the custom policy script or executable contains spaces, specify quotation marks (") around the path.
To implement a custom policy:
Write a policy script or executable.
Log on to a DRA client computer with an account that is assigned the built-in Manage Policies and Automation Triggers role in the managed domain.
Start the Delegation and Configuration console.
Connect to the primary Administration server.
In the left pane, expand Policy and Automation Management.
Click Policy.
On the Tasks menu, click New Policy > Create a Custom Policy.
On each wizard window, specify the appropriate values, and then click Next. For example, you can associate this new policy with a specific ActiveView, allowing DRA to enforce this policy on objects included by that ActiveView.
Review the summary, and then click Finish.
To modify all the properties of a policy, you must have the appropriate powers, such as those included in the built-in Manage Policies and Automation Triggers role.
To modify policy properties:
Navigate to Policy and Automation Management > Policy.
Right-click the policy you want to modify, and select Properties.
Modify the appropriate properties and settings for this policy.
For more information about writing a custom policy scripts or executables, see the SDK.
To access the SDK:
Ensure that you have installed the SDK on your computer. The setup program creates a shortcut to the SDK in the Directory and Resource Administrator program group. For more information, see the installation checklist at Install the DRA Administration Server.
Click the SDK shortcut in the Directory and Resource Administrator program group.
For more information about SDK, see the DRA REST Services Guide
on the DRA Documentation site.