Privileged Mode
Privileged Mode
This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
When you run a workflow application in privileged mode, the workflow engine verifies that your design-time objects are authored by someone with proper privileges. The following table summarizes the privileged mode characteristics.
Feature | Description |
---|---|
Script or Component Object Model (COM) actions | The workflow action can be either script or a call to a registered COM object. |
No script sandboxing | The workflow engine allows the use of CreateObject for any valid classID on the system including the FileSystem object, all Collaboration Data Objects (CDO) or Microsoft® ActiveX® Data Objects (ADO) objects, and so on. |
Script runs as Workflow System Account | The script host executes the script under the same Microsoft Windows® server operating systems security account as the caller. No impersonation occurs. In the default case for the CDO Workflow event sink, this means that the script will run in the Workflow System Account, which typically has full administrative permissions to most Microsoft Exchange Server 2003 resources. |
The following illustration demonstrates how workflow processes run in privileged mode.
Send us your feedback about the Microsoft Exchange Server 2003 SDK.
Build: June 2007 (2007.618.1)
© 2003-2006 Microsoft Corporation. All rights reserved. Terms of use.