Exchange Administration
The Exchange Administration Service Type allows the management of Exchange mailboxes. The broker exposes methods to enable and disable Exchange mailboxes. This service is used internally by the product for some of the Exchange workflow wizards.
An instance this Service Broker is configured during the upgrade process if Exchange integration had been configured for your system. You can manually create additional instances.
Service Authentication
The following Authentication Modes may be used with the Service Type:
- Impersonate
- ServiceAccount
- Single Single-on
- Static
Service Keys (Service Instance Configuration Settings)
| Key | Can be modified | Data Type | Sample Value | Notes |
|---|---|---|---|---|
| Exchange EWS URL | Yes (required) | Text | http://dlx.denallix.com/EWS/Exchange.asmx | The URL of the Exchange Web Services. |
| Exchange Version | Yes (required) |
Text |
Exchange2010 Exchange2013 |
The version of Microsoft Exchange that has been configured for use with the server |
| Use Auto Discovery | Yes | True/False | True | |
| Is Exchange Online | Yes | True/False | False | Set this value to True if you are targeting an Exchange Online environment. |
Service Objects
The Exchange Administration Service Instance contains the Exchange Mailbox Service Object.
SmartObjects
If an Exchange environment is configured during installation of the product, it automatically generates SmartObjects for the Service Objects. These SmartObjects are used by the Exchange Event Wizards when enabling or disabling mailboxes in a process event wizard. SmartObjects can be automatically created by selecting the Generate SmartObjects for this Service Instance check box when creating a new Service Instance. Designers can use the SmartObject design tools to build advanced SmartObjects that leverage the Service Objects in this service. It is recommended to use the SmartObject design tools to create SmartObjects rather than generating SmartObjects, since this allows better control over the naming, behavior and design of the SmartObject and its methods and properties.
Considerations
The default Service Instance of this service is used internally by the environment. Do not modify or delete the existing service instance. You can create a new instance or use the methods from the existing instance
Using Impersonation for SmartObject methods at runtime
When using Impersonate as the Service Instance Authentication mode, additional requirements may apply to allow users to call SmartObject methods that perform Exchange Administration operations. (The Exchange SmartObject methods use PowerShell to communicate with Exchange). This method is recommended instead of using the service account for the Exchange integration.
- The account making the call must be a Windows account and it must use the security label that uses SSPI for authentication (by default this security label is called K2 and is associated with AD users).
- The Windows account making the call must have a cached credential.
- When Run As is configured on a server event, the alternate credential is cached automatically.
- The Service Instance must be set up to use “Impersonation” and “Enforce Impersonate”.
WinRM Limitation may cause failures in high-load environments
The WinRM architecture (which PowerShell uses to communicate with Exchange) limits the number of connections that a single user is allowed to open concurrently (the default is 18). If a large number of concurrent calls are made via the Exchange SmartObjects, this limit may be reached and subsequent calls fail.
| Affected Services | Methods |
|---|---|
| ExchangeAdminService |
|
| ExchangeMetadataService |
|
| ExchangeService |
|
If your Exchange events sometimes fail during busy times, you can execute one of the following commands to increase the default number of connections.
winrm set winrm/config/winrs @{MaxShellsPerUser="50"}
or
Set-Item WSMan:\localhost\Shell\MaxShellsPerUser 50