Lync Server User Management
Skype for Business Server User Management
Active Roles now includes a user management solution—Skype for Business Server User Management—to provision Skype for Business Server user accounts in Active Directory environments with a single forest or multiple forests.
The Skype for Business Server User Management solution enables Active Roles to administer Skype for Business Server user accounts. This solution provides built-in policies that synchronize user account information between Active Roles and Skype for Business Server, allowing Skype for Business Server user management tasks to be performed using the Active Roles Web Interface.
With Skype for Business Server User Management, you can use Active Roles to perform the following tasks:
- Add and enable new Skype for Business Server users
- View or change Skype for Business Server user properties and policy assignments
- Move Skype for Business Server users from one Skype for Business Server pool to another
- Disable or re-enable user accounts for Skype for Business Server
- Remove users from Skype for Business Server
Skype for Business Server User Management adds the following elements to Active Roles:
- Built-in Policy Object containing a policy that enables Active Roles to perform user management tasks on Skype for Business Server.
- Built-in Policy Object containing a supplementary policy that enables Active Roles to administer Skype for Business Server users in environments that involve multiple Active Directory forests.
- Commands and pages for managing Skype for Business Server users in the Active Roles Web Interface.
- Access Templates to delegate Skype for Business Server user management tasks.
The Skype for Business Server User Management policy allows you to control the following factors of Skype for Business Server user creation and administration:
- Rule for generating the SIP user name. When adding and enabling a new Skype for Business Server user, Active Roles can generate a SIP user name based on other properties of the user account.
- Rule for selecting a SIP domain. When configuring the SIP address for a Skype for Business Server user, Active Roles can restrict the list of selectable SIP domains and suggest which SIP domain to select by default.
- Rule for selecting a Telephony option. When configuring Telephony for a Skype for Business Server user, Active Roles can restrict the list of selectable Telephony options and suggest which option to select by default.
- Rule for selecting a Skype for Business Server pool. When adding and enabling a new Skype for Business Server user, Active Roles can restrict the list of selectable registrar pools and suggest which pool to select by default. This rule also applies to selection of the destination pool when moving a Skype for Business Server user from one pool to another.
Skype for Business Server User Management provides a number of Access Templates allowing you to delegate the following tasks in Active Roles:
- Add and enable new Skype for Business Server users
- View existing Skype for Business Server users
- View or change the SIP address for Skype for Business Server users
- View or change the Telephony option and related settings for Skype for Business Server users
- View or change Skype for Business Server user policy assignments
- Disable or re-enable user accounts for Skype for Business Server
- Move users from one Skype for Business Server pool to another
- Remove users from Skype for Business Server
Supported Active Directory topologies
Skype for Business Server User Management supports the same Active Directory Domain Services (AD DS) topologies as Microsoft Lync 2013. The following topologies are supported:
- Single forest with a single tree or multiple trees
- Multiple forests in a resource forest topology
- Multiple forests in a central forest topology
Single forest
The single forest topology assumes that the logon-enabled user accounts managed by Active Roles are defined in the Active Directory forest in which Skype for Business Server is deployed. To perform Skype for Business Server user management tasks on a given user account, Active Roles makes changes to the attributes of that use account, and then, based on the attribute changes, the Skype for Business Server User Management policy requests the Skype for Business Server remote shell to update the user account accordingly. For example, when creating a new Skype for Business Server user, Active Roles sets a virtual attribute on that user’s account directing the policy to invoke the remote shell command for enabling the new user for Skype for Business Server. When making changes to an existing Skype for Business Server user, Active Roles populates the attributes of the user’s account with the desired changes, causing the policy to apply those changes via the remote shell.
Multiple forests - Resource forest
The resource forest topology refers to a multi-forest environment where a separate forest—Skype for Business Server forest—hosts servers running Skype for Business Server but does not host any logon-enabled user accounts. Outside the Skype for Business Server forest, user forests host logon-enabled user accounts but no servers running Skype for Business Server. When creating a Skype for Business Server account for a user from an external forest, Active Roles creates a disabled user account in the Skype for Business Server forest, establishes a link between the user account in the user forest (master account) and the disabled user account in the Skype for Business Server forest (shadow account), and enables the shadow account for Skype for Business Server. The Master Account Management policy then ensures that the attributes of the shadow account are synchronized with the attributes of the master account, so that Skype for Business Server user properties can be administered on the master account via Active Roles. In the Skype for Business Server forest, the User Management policy detects the attribute changes replicated from the master account to the shadow account, and translates them to remote shell commands on Skype for Business Server, similarly to the Single forest case.
Multiple forests - Central forest
The central forest topology refers to a multi-forest environment where a separate forest—Skype for Business Server forest—hosts servers running Skype for Business Server and may also host logon-enabled accounts. Outside the Skype for Business Server forest, user forests host logon-enabled user accounts but no servers running Skype for Business Server.
With the Skype for Business Server User Management policy applied to logon-enabled user accounts in the Skype for Business Server forest, Active Roles can enable and administer those user accounts for Skype for Business Server in the same way as in the Single forest case.
When creating a Skype for Business Server account for a user from an external forest, Active Roles creates a contact in the Skype for Business Server forest, establishes a link between the user account in the user forest (master account) and the contact in the Skype for Business Server forest (shadow account), and enables that contact for Skype for Business Server. The Master Account Management policy then ensures that the attributes of the contact are synchronized with the attributes of the user account, so that Skype for Business Server user properties can be administered on the user account via Active Roles. In the Skype for Business Server forest, the User Management policy detects the attribute changes replicated from the user account to the contact, and translates them to remote shell commands on Skype for Business Server, similarly to the Single forest case.
How to start
For instructions on how to install, configure and user Skype for Business Server User Management, see the Solution Guide document for Active Roles 8.0 LTS.
Workflow activity: Save Object Properties
Save Object Properties activity is intended to save properties of a particular object at workflow execution time. The properties are saved in the workflow data context, and can be retrieved by other activities before or after the object has changed. This capability is instrumental in situations that require knowing not only the changed object state or properties but also the previous or old values of certain properties. Old values may be required to determine the previous state of an object in order to make some decision or perform a certain action based on those values. For example, to notify of object deletions, you can create a workflow that starts when deletion of an object is requested, saves the object’s name, and then, after the object is deleted, sends a notification message that includes the saved name of the deleted object.
This activity has the following configuration options:
- Activity target This option lets you specify the object whose properties you want the activity to save. You can choose to specify:
- Workflow target object In a change workflow, the target object of the request that started the workflow. For example, in a workflow that starts upon a deletion request, this choice causes the activity to save the properties of the object whose deletion is requested.
- Fixed object in directory A particular object you select from Active Directory.
- Object identified by workflow parameter The object specified by the value of a certain parameter of the workflow. You can choose the desired parameter from the workflow definition.
- Object from workflow data context The object will be selected by the activity on the basis of the data found in the workflow environment at the time of executing the workflow. You can specify which object you want the activity to select at workflow execution time.
- Object identified by DN-value rule expression The object whose Distinguished Name (DN) is specified by the string value of a certain rule expression. By using a rule expression you can compose a string value based on properties of various objects found in the workflow environment at the time of executing the workflow. You can create the desired rule expression when you configure the activity.
- Target properties This option lets you specify the object properties you want the activity to save. The workflow designer proposes the default list of properties, and allows you to change the list as needed. By default, the activity saves all single-value non-constructed attributes found in the directory schema for the target object, including custom virtual attributes added to the directory schema by Active Roles.
- Notification You can configure the activity to subscribe recipients to the notifications of the following events:
- Activity completed successfully When configured to notify of this event, the activity causes Active Roles to send a notification e-mail if no significant errors occurred during execution of this activity.
- Activity encountered an error When configured to notify of this event, the activity causes Active Roles to send a notification e-mail if any significant errors occurred during execution of this activity.
The notification settings specify the event to notify of, and notification recipients. When executed by the workflow, the activity prepares a notification message appropriate to the specified event. Active Roles retains the message prepared by the activity, and sends the message to the specified recipients upon occurrence of that event.
- Error handling You can choose whether to suppress errors encountered by the activity. The following option is available: Continue workflow even if this activity encounters an error. If this option is not selected (default setting), then an error condition encountered by the activity causes Active Roles to terminate the workflow. If you select this option, the workflow continues regardless of whether or not the encounters an error condition.
Retrieving saved properties
In a workflow that includes an activity of the Save Object Properties type, you can configure other activities to retrieve object properties saved by that activity:
- By using the following expression in a Script activity: $workflow.SavedObjectProperties("activityName").get("attributeName")
In this expression, activityName stands for the name of the Save Object Properties activity and attributeName is the LDAP display name of the attribute representing the property you want the script to retrieve. You should specify an attribute listed in the Target properties setting of the “Save Object Properties” activity; otherwise, this expression returns no property value at workflow execution time.
- By adding the Workflow - Saved Object Properties token to the notification message template.
To add the token:
- In the Insert Token dialog box, click Workflow - Saved Object Properties in the list of tokens, and then click OK.
- In the dialog box that appears, select the name of the Save Object Properties activity and the saved property you want the token to retrieve.
You should select a property listed in the Target properties setting of the Save Object Properties activity; otherwise, the token you have configured returns no property value at workflow execution time.
- By choosing the Property of object from workflow data context configuration option, available in If-Else branch conditions, Search filter, “Create” activity, “Update” activity, and Add Report Section activity.
If you choose this option, then you need to perform the following configuration steps:
- In the Object Property dialog box, click the link in the Target object field, and then click More choices.
- In the dialog box that appears, click Saved Object Properties in the left pane, select the name of the Save Object Properties activity from the Activity list, and then click OK.
- In the Object Property dialog box, click the link in the Target property field, and select the property you want.
You should select a property listed in the Target properties setting of the Save Object Properties activity; otherwise, the entry you have configured returns no property value at workflow execution time.
How to start
For configuration instructions, see the “Configuring a Save Object Properties activity” section in the Active Roles 8.0 LTS Administration Guide.
Workflow activity: Modify Requested Changes
Modify Requested Change activity is intended to update the change request that started the workflow, allowing you to add or remove changes to the properties of the workflow target object at workflow execution time. For example, in a workflow that starts when creation of an object is requested, you can use this activity to modify the properties that are going to be assigned to the new object, or change the container in which to create the object. In a workflow that starts upon a request to change an object, you can use this activity to modify the requested changes to the properties of that object.
This activity has the following configuration options:
- Target changes You can define the property changes to add or remove from the change request. When you configure this activity, you can choose the properties you want the activity to change and, for each property, choose to remove the property from the request, clear the property value in the request, or specify the new value to be assigned to that property. For a multi-value property, you can choose to add or remove a value from that property. The following options are available:
- Text string Use the given string of characters as the value of the property. You can type the desired string.
- Property of workflow target object Use the value of a certain property of the target object of the request that started the workflow. You can select the desired property from a list of object properties.
- Property of workflow initiator Use the value of a certain property of the user whose request started the workflow. You can select the desired property from a list of object properties.
- Changed value of workflow target object property Use the value that is requested to be assigned to a certain property of the workflow target object. You can select the desired property from a list of object properties.
- Workflow parameter value Use the value of a certain parameter of the workflow. You can choose the desired parameter from a list of the workflow parameters.
- Property of object from workflow data context Use the value of a certain property of the object that will be selected by the activity on the basis of the data found in the workflow run-time environment. You can choose the desired property and specify which object you want the activity to select at workflow run time.
- Value generated by rule expression Use the string value of a certain rule expression. By using a rule expression you can compose a string value based on properties of various objects found in the workflow run-time environment. You can create the desired rule expression when you configure the activity.
- Notification You can configure the activity to subscribe recipients to the notifications of the following events:
- Activity completed successfully When configured to notify of this event, the activity causes Active Roles to send a notification e-mail if no significant errors occurred during execution of this activity.
- Activity encountered an error When configured to notify of this event, the activity causes Active Roles to send a notification e-mail if any significant errors occurred during execution of this activity.
The notification settings specify the event to notify of, and notification recipients. When executed by the workflow, the activity prepares a notification message appropriate to the specified event. Active Roles retains the message prepared by the activity, and sends the message to the specified recipients upon occurrence of that event. The notification settings are similar to the notification settings of a Notification activity.
- Error handling You can choose whether to suppress errors encountered by the activity. The following option is available: Continue workflow even if this activity encounters an error. If this option is not selected (default setting), then an error condition encountered by the activity causes Active Roles to terminate the workflow. If you select this option, the workflow continues regardless of whether or not the encounters an error condition.
- Additional settings You can configure the activity to:
- Change the container where to create new objects while ensuring that the policies and workflows are applied from the container where the object will actually be created rather than from the container that was originally specified in the object creation request.
- Add or remove Active Roles controls from the request.
Controls are certain pieces of data that can be used to provide additional information to Active Roles on how to process the request. If no controls are added to a request, then Active Roles determines how to process the request based solely on the type of the request. You can configure the activity to add certain controls to the request (include controls) or to ensure that certain controls never occur in the request (exclude controls). For information about Active Roles controls, see Active Roles SDK.
NOTE: The Modify Requested Changes activity type is unavailable in case of an automation workflow. You can add activities of this type to a change workflow only.
How to start
For configuration instructions, see the “Configuring a Modify Requested Changes activity” section in the Active Roles 8.0 LTS Administration Guide.
Workflow feature: Initialization script
When executing a workflow instance, Active Roles uses a single PowerShell operating environment, referred to as a runspace, for all script activities held in that workflow. The workflow run-time engine creates a runspace once the workflow instance has been started, and maintains the runspace during the execution of the workflow instance.
When you configure a workflow, you can specify PowerShell commands you want the workflow run-time engine to execute immediately after the runspace creation. These commands constitute the initialization script that the workflow engine runs prior to performing script activities.
With an initialization script, you can define runspace configuration data separately from the logic of the script activities and use it to initialize the environment for executing script activities. Specifically, you can:
- Load PowerShell modules and snap-ins. All activity scripts can use the modules and snap-ins loaded in the initialization script, without having to load the prerequisite modules or snap-ins on a per-activity basis.
The modules and snap-ins loaded in the initialization script are available to all script activities at workflow run time. For example, the Import-Module 'SmbShare' command added to the initialization script makes the Server Message Block (SMB) Share-specific cmdlets available to all script activities within the workflow.
- Initialize environment-specific variables, referred to as global variables. All activity script can retrieve and update global variables, which makes it possible to exchange data between different activity scripts.
The global variables are visible to all script activities at workflow run time. For example, the $rGuid = [Guid]::NewGuid() command added to the initialization script makes the $rGuid variable available to all script activities within the workflow. To reference a variable that is defined in the initialization script, the activity script must use the $global: qualifier, such as $global:rGuid.
When execution of the workflow instance is suspended (for example, waiting for approval), and then resumed (for example, after receiving an approval decision), the runspace is reinitialized so the global variables may change. If you need to preserve the value of a global variable, add the [Persist()] attribute to the variable's name in the initialization script, such as [Persist()]$rGuid = [Guid]::NewGuid(). The global variables defined in this way are saved to a persistent storage upon suspending the workflow instance and restored from the storage when the workflow instance is resumed. To save a variable, Active Roles creates and stores an XML-based representation of the object signified by that variable, similarly to the Export-Clixml command in Windows PowerShell. When restoring the variable, Active Roles retrieves the XML data that represents the object, and creates the object based on that data, similarly to the Import-Clixml command.
How to start
- In the Active Roles console tree, expand Configuration | Policies | Workflow, and select the workflow you want to configure.
This opens the Workflow Designer window in the details pane, representing the workflow definition as a process diagram.
- In the details pane, click the Workflow options and start conditions button to expand the area above the process diagram, and then click the Configure button.
- Click the Initialization script tab in the dialog box that opens.
The Initialization script tab displays the current script. You can add or modify the script by typing in the edit box on that tab.
