Start-BrokerSessionRecording
Starts recording the specified session(s).
Syntax
Start-BrokerSessionRecording
[-Sessions] <Session[]>
[-NotifyUser <Boolean>]
[-LoggingId <Guid>]
[<CitrixCommonParameters>]
[<CommonParameters>]
Start-BrokerSessionRecording
[-User] <User>
[-NotifyUser <Boolean>]
[-LoggingId <Guid>]
[<CitrixCommonParameters>]
[<CommonParameters>]
Description
Starts recording the specified session(s).
Only active sessions using the HDX protocol can be recorded. An error appears when unqualified sessions (non-existent, inactive, or non-HDX) are specified for recording. No warning appears when you trigger an action to record sessions that are already being recorded.
Examples
EXAMPLE 1
Starts recording the session Uid 10,11,12 without notifying the user.
Start-BrokerSessionRecording -Sessions 10,11,12 -NotifyUser 0
EXAMPLE 2
Starts recording all sessions of user Geffrey in the domain named MYDOMAIN and notifies user Geffrey.
Start-BrokerSessionRecording -User MYDOMAIN\Geffrey -NotifyUser 1
Parameters
-Sessions
Specifies the session(s) to be recorded.
| Type: | Session[] |
| Position: | 2 |
| Default value: | None |
| Required: | True |
| Accept pipeline input: | True (ByValue) |
| Accept wildcard characters: | False |
-User
Specifies the user whose session is to be recorded.
| Type: | User |
| Position: | 2 |
| Default value: | None |
| Required: | True |
| Accept pipeline input: | True (ByValue) |
| Accept wildcard characters: | False |
-NotifyUser
Determines whether to notify the end user of the recording activity.
| Type: | Boolean |
| Position: | Named |
| Default value: | True |
| Required: | False |
| Accept pipeline input: | False |
| Accept wildcard characters: | False |
-LoggingId
Specifies the identifier of the high level operation that this cmdlet call forms a part of. Desktop Studio and Desktop Director typically create High Level Operations. PowerShell scripts can also wrap a series of cmdlet calls in a High Level Operation by way of the Start-LogHighLevelOperation and Stop-LogHighLevelOperation cmdlets.
| Type: | Guid |
| Position: | Named |
| Default value: | None |
| Required: | False |
| Accept pipeline input: | False |
| Accept wildcard characters: | False |
CitrixCommonParameters
This cmdlet supports the common Citrix parameters: -AdminAddress, -AdminClientIP, -BearerToken, -TraceParent, -TraceState and -VirtualSiteId. For more information, see about_CitrixCommonParameters.
CommonParameters
This cmdlet supports the common parameters: -Debug, -ErrorAction, -ErrorVariable, -InformationAction, -InformationVariable, -OutVariable, -OutBuffer, -PipelineVariable, -Verbose, -WarningAction, and -WarningVariable. For more information, see about_CommonParameters.
Inputs
Citrix.Broker.Admin.SDK.Session
The session(s) to be recorded.
Citrix.Broker.Admin.SDK.User
The user whose sessions are to be recorded.
Outputs
None
By default, this cmdlet returns no output.
Notes
Sessions can be passed using the Sessions parameter as session objects or session Uids. A user can be passed using the User parameter as a user object or a user name.
This operation is non-blocking and returns before it completes. The operation, however, is unlikely to fail unless there are communication problems between the Delivery Controller and the VDA, or if bad arguments are passed to the cmdlet itself, or if the VDA cannot successfully execute the operation.
The Delivery Controller can fail to invoke the operation if the VDA is not in an appropriate state or if there are problems with communicating with the VDA. When an operation is invoked, the Delivery Controller detects and reports whether the operation is initiated successfully on the VDA. However, because the operation is non-blocking, the Delivery Controller does not detect or report whether or not the operation ultimately succeeds after the operation is initiated successfully.
Operation failures are reported through the Broker SDK error handling mechanism (see about_Broker_ErrorHandling). In the event of errors, the SdkErrorRecord error status code is set to SessionOperationFailed and its error data dictionary is populated with the following entries:
-
OperationsAttemptedCount: The number of operations attempted.
-
OperationsFailedCount - The number of failed operations.
-
OperationsSucceededCount - The number of successful operations.
The SdkErrorRecord message displays the number of attempted, failed, and successful operations in the following format:
"Session operation error - attempted:\<OperationsAttemptedCount\>, failed:\<OperationsFailedCount\>, succeeded:\<OperationsSucceededCount\>"