Collapse All Expand All

Authenticating with Microsoft Exchange as the User Making the SmartObject Call

The Exchange SmartObject methods that use PowerShell to communicate with Exchange now support authenticating with Exchange as the user making the SmartObject call. The following conditions must be met for the call to succeed:

• 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”).
• The Windows account making the call must have a cached credential.
  • This can be done in Workspace.
  • Alternatively when Run As is used the credential will be cached automatically.
• The service object must be set up to use “Impersonation” and “Enforce Impersonate”.
  • Currently additional configuration required (SPNs etc.) is not known for “Impersonation” without “Enforce Impersonate”. In theory this would be used to avoid having to cache credentials.

We recommend that this method is used, as using the K2 service account for the Exchange PowerShell calls is a security concern.

Large Number of Method Calls

The WinRM architecture (which PowerShell uses to communicate with Exchange) limits the number of connections that a single user is allowed to open concurrently (by default this is 18). If a large number of concurrent calls are made to the SmartObjects this limit may be reached and the call will fail.

Affected Services/Methods

• ExchangeAdminService
  • EnableMailbox
  • DisableMailbox
• ExchangeMetadataService
  • GetExchangeServer
  • GetMailboxDatabase
  • GetCurrentUser
• ExchangeService
  • EnableMailbox
  • DisableMailbox
  • GetExchangeServer
  • GetMailboxDatabase
  • GetCurrentUser
    

The following commands demonstrate two ways to increase the default number of connections:

winrm set winrm/config/winrs @{MaxShellsPerUser="50"}

or

Set-Item WSMan:\localhost\Shell\MaxShellsPerUser 50

 

 

---

K2 blackpearl Help 4.6.10 (4.12060.1690.0)