Platform server management cmdlets
The platform server management cmdlets allow you to do the following:
- Specify the platform server to connect to and verify its version.
- Manage device tags.
- Retrieve workflow notifications.
- Manage event subscriptions and assignments.
For information about event management, refer to Event management cmdlets.
Set-1EServer <server name> ...
[-ApiKey <api key>]
[-Credential <credentials>]
[-AppId <appId>]
[-CertSubject <CertSubject>]
[-CertThumbprint <CertThumbprint>]
[-Principal <principal>]
[-UseBasicAuth]
[-BypassAuth]
[-AsPlatform]
[-KeyVaultUrl <KeyVaultUrl>]
[-ManagedIdentity <ManagedIdentity>]
[-CertName <CertName>]
[ -Secret <secret> ]
[ -VaultAppId <appid> ]
[ -Certificate <certificate> ]
|
Parameter |
Description |
|---|---|
|
server name |
Specifies the platform server to be used for all operations. A connectivity test is made when this cmdlet is executed. An error is thrown if the server does not respond appropriately. If the server is determined to be a Consumer Authentication Proxy server, then unless client certificate authentication or inbound NTLM authentication is configured on the proxy, the optional ApiKey parameter should specify a valid API access token. If using Windows authentication, the connection is made by default in the context of the current account in which the cmdlet is being run. You can override this with the -Credential argument by specifying a PSCredential object with alternate credentials. The connection will then be made in the context of those credentials and all subsequent commands will also run in that context. This can be very useful when connecting to external servers, for example, SaaS-based environments, where the credentials are required to be valid in that environment. To prompt securely for credentials when invoking this cmdlet, you can use the get-credential PowerShell cmdlet. For example -Credential (get-credentials). Alternatively you can store the credentials in a PowerShell variable and pass this as the value of the -Credential parameter, for example, -Credential $myCreds. If the server is configured for platform-neutral authentication, and you do not specify an Application Id and Certificate to authenticate non-interactively, then you will instead be prompted to authenticate via the configured identity provider. This process will use the default browser on the device you are using. |
|
UseBasicAuth |
Specifies that the connection will be made using basic authentication. In this case you must supply credentials via the -Credential parameter. |
|
AppId |
Specifies that connectivity is to be made by platform-neutral authentication, that is, through an external identity provider. The application Id should correspond to a registered application which has been set up on the identity provider to handle external authentication. If the AppId parameter is specified, you must also specify a certificate subject (for example, CN=MyCert) that is to be used to sign the token that is used to authenticate the 1E PowerShell Toolkit to the 1E Platform. |
|
CertSubject |
Specifies the subject of the certificate to be used when authenticating using platform-neutral authentication. |
|
CertThumbprint |
Specifies the thumbprint of the certificate to be used when authenticating using platform-neutral authentication. If both a CertSubject and CertThumbprint parameter are specified, the CertThumbprint value is used in preference. The certificate must be in the local machine certificate store, and the account under which you are running the tool must have access to the private key. You can use the manage private key option in the certlm.msc tool to add permissions if necessary. |
|
Principal |
If specified, it defines the user principal associated with the authentication token. This parameter is only valid if the certificate to principal mappings have been set up to allow principals to be overridden. Otherwise, the user principal associated with the authentication token will be automatically defined by the mapping table entries. |
|
BypassAuth |
If specified, it simply causes the internal tachyon server variable to be set, and then the cmdlet exits. After this, you can call any endpoint on the 1E Platform that is not authenticated. This is useful for troubleshooting because you can then use cmdlets such as Get-1EBearerToken to check identity provider configuration, for example. |
|
AsPlatform |
If specified, it requests a internal platform token. You must specify a certificate subject or thumbprint but you do not need to supply a principal or application Id, because platform tokens are not mediated via the external identity provider. A platform token operates with extended privileges. The certificate you specify must have its private key accessible under the account context from which you are running the 1E PowerShell Toolkit. This option is useful if you want to interact with the 1E Platform during commissioning as it does not rely on the external identity provider. |
|
KeyVaultUrl |
If specified, it defines the URL of the Azure Key Vault from which the certificate is to be retrieved. The URL should not contain the https:// prefix; this is added automatically. You must specify -ManagedIdentity and -CertName when using this parameter. |
|
ManagedIdentity |
If specified, it defines the managed identity that the key vault access should be made under. Normally, the virtual machine on which the Toolkit is running in the Azure environment will be assigned this managed identity and the managed identity needs to have the appropriate permissions to read the Azure Key Vault. |
|
CertName |
If specified, it defines the name of the certificate to be retrieved from the key vault. Note that certificate names and subjects are entirely independent of each other in the vault. |
|
Secret |
If specified, it defines the shared secret to be used to access the key vault. This is useful where the caller is not running in a context with an assigned managed identity. |
|
VaultAppId |
If specified, it defines the application to which the oAuth grant request will be made to access the key vault. This is ignored when a managed identity is specified but required when a secret is supplied. |
|
Certificate |
If specified, it defines an X509 certificate object which is to be used directly when authenticating. |
For information on setting up access to the Azure Key Vault, refer to Accessing the Azure Key Vault using REST and oAuth.
Azure Key Vault access is also available on non-Windows (Linux) platforms. For more information, refer to Using the 1E PowerShell Toolkit on non-Windows platforms.
The Consumer Authentication Proxy server is a custom feature that can be provided on request. Please contact your 1E Account Manager.
Set-1EProxyCredentials -ApiKey <api key> [-Credentials <credentials>]
This cmdlet allows a set of credentials to be sent and stored on the Consumer Authentication Proxy server. The proxy server will use these credentials when mapping incoming requests to outgoing platform requests.
If you do not pass a PSCredential object on the command line, you are securely prompted for credentials instead.
The value of the API key for this cmdlet is configured on the proxy server separately from the API key used in the Set-1EServer cmdlet. You must obtain a value for both keys from the proxy administrator.
Get-1EServer
This cmdlet returns the currently configured platform server. An error is thrown if no server is configured .
Get-1EAuthToken [-Decode]
This cmdlet returns the current authentication token (if any). An authentication token is available if the -AppId and -CertStore parameters were supplied to the Set-1EServer cmdlet to request platform-neutral authentication, or if the user has interactively authenticated with the configured identity provider.
The -Decode parameter returns the token as a PowerShell object rather than in its native base-64 encoded format.
Update-1EAuthToken
This cmdlet refreshes the current authentication token and updates it with the refreshed version.
Get-1EBearerToken -AppId <appid> [ -CertSubject <cert subject> ] [-MetadataEndpoint <metadata endpoint>] [-Certificate <certificate>] [ -Secret <secret> ] [ - Scope <scope> ] [ -ManagedIdentity <managed id> ]
This cmdlet retrieves a bearer token directly from the identity provider that is associated with the platform, via the application whose Id is specified. This is useful if you are trying to troubleshoot authentication issues because you can communicate directly with the identity provider and bypass the 1E Platform during testing. You can then use the returned bearer token to call APIs on the identity provider for further troubleshooting if you wish. You can retrieve a bearer token either interactively on non-interactively. Refer to Retrieving a bearer token interactively and Retrieving a bearer token non-interactively.
The -AppId parameter specifies the application Id which is to be used to request the bearer token.
If the -ManagedIdentity parameter is specified, then a bearer token is directly requested using the client Id of the Managed Identity specified. In this case, the -Certificate, -Secret, -CertSubject, -AppId, and -MetadataEndpoint parameters are ignored.
The certificate subject defines the subject of a certificate in the local machine certificate store whose private key is used to sign the JWT (Json Web Token) which is sent to the identity provider.
The -Certificate parameter defines an X509Certificate2 object which contains the entire certificate and can be used instead of specifying a certificate subject for searching the local machine certificate store.
The optional -Metadata parameter allows you to directly specify the identity provider metadata endpoint. Bearer token requests will be made to the token endpoint that this metadata endpoint returns when queried. If this parameter is not specified, the 1E Platform is contacted to determine the metadata endpoint of the associated identity provider.
If you do not specify a metadata endpoint, you must call set-1Eserver first to define the platform server. If you are troubleshooting authentication issues, use the -BypassAuth parameter to that cmdlet. This will set the server but without attempting to authenticate. You can then use the Get-1EBearerToken cmdlet to troubleshoot identity provider configuration issues.
The -Secret parameter allows you to specify a shared secret instead of a certificate. In this case the bearer token is retrieved using the oAuth Client Credentials grant flow instead of the client assertion grant flow. This is intended for identity providers, such as Ping, which do not support the client assertion grant flow.
Normally, the shared secret is only used by the platform and is not made available to external integration consumers. These still use signed JWTs, but in this scenario, the platform verifies these instead of the identity provider and then uses the shared secret internally to obtain a bearer token from the identity provider.
Shared secrets are also useable in interactive authentication scenarios involving Azure. Currently, the platform doesn't directly support this, but there may be a future change for this because it mitigates an issue with Azure Conditional Access Policies, which is discussed below. Refer to Retrieving a bearer token interactively.
The -Scope parameter allows you to specify a particular scope that you wish the bearer token to possess. Normally, the default scope appropriate for the identity provider is used. However, for some applications, you may wish to specify a different scope. For example, to obtain a bearer token that can access the Azure Key Vault, you need to request the scope https://vault.azure.net/.default.
By default, a bearer token is returned with the scope .default for Azure and okta.users.read for Okta. If you want a bearer token with a refresh component, you must request a scope that includes offline_access. To specify multiple scopes, enclose them in quotes, separating each scope with a space. Note that scope names are identity provider specific.
In the above example, note that the application you are obtaining the bearer token from must also have been granted appropriate API permissions against the key vault, and the service principal associated with the application must also have been granted appropriate permissions from within the key vault management screen (IAM).
Retrieving a bearer token interactively
- You must specify the application id (-AppId) of an application configured to support the PKCE oAuth grant flow.
- You must configure this application on the identity provider to support an additional redirect address of http://localhost:8080. You can remove this redirect address after testing is complete, but it is required here because the entire grant flow will be conducted on your local machine and not by the platform.
- You must either specify the metadata endpoint for the identity provider instance or, if you omit it, you must have connected to the platform first with the set-1eserver cmdlet so that the Toolkit knows which endpoint to request the metadata endpoint from.
- You can specify a shared secret. This supports Azure AD specifically where it is possible to configure an application that supports the PKCE grant flow but which also requires a shared secret. You do this by configuring a Web platform against the app in Azure rather than an SPA platform. Note that currently, the platform doesn't directly support this for authentication, but these applications do have the advantage that if a conditional access policy setting multi-factor authentication disabled inside a corporate perimeter is set up by a customer, a web application will not refuse the token code exchange part of the grant flow, whereas an SPA-configured app will refuse the request if it comes from outside the perimeter, and the IP address of the platform issuing the request isn't whitelisted in Azure. Therefore, the platform may be enhanced in due course to support this option.
You can specify the -BypassAuth parameter in the above scenario to skip platform authentication. This is helpful where you are trying to pinpoint an authentication failure where you may have platform configuration issues and/or identity provider configuration issues. Specifying -BypassAuth when invoking set-1eserver causes the Toolkit to merely record the server URL you wish to connect to and to contact its unauthenticated endpoint to retrieve the metadata endpoint of the identity provider automatically.
Retrieving a bearer token non-interactively
- You must specify the application Id of an application configured to support the client assertion oAuth grant flow.
- You can specify either a certificate, a secret, or a managed identity to authenticate with.
- If you are using a certificate to authenticate, that application must have had the public key portion of the certificate you're using to sign the JWT that will be submitted to the identity provider.
- The account you're running the Toolkit in must have access to the private key of the certificate, which is assumed is stored in the local machine\personal cert store on the machine you're running the toolkit on
- If you are using a secret, then the application must have that shared secret created. Note that when creating shared secrets, once they're created and you close the form, you can't get them back, so note them down carefully.
- If you are using a managed identity, then the machine you're running the Toolkit on must have been assigned that managed identity.
This cmdlet is intended for test purposes. Bearer tokens are not directly useable within the platform.
For examples of using returned bearer tokens to call identity provider APIs, refer to Using Bearer Tokens to access identity provider APIs.
Invoke-1EIdentityProviderAPI -Token <bearer token> -Url <API url>
This cmdlet invokes the specified identity provider API using a bearer token obtained from the Get-1EBearerToken cmdlet.
For example, for Okta, you could retrieve the current user profile, given a bearer token obtained interactively, with the following call (changing the URL to match your identity provider). Note that these examples wouldn't work if you used a bearer token obtained non-interactively as there isn't an identity component inside these bearer tokens. However, other identity provider APIs can be called by both interactive and non-interactive tokens. The scope(s) granted to the bearer token determine the privileges you have and hence which APIs are permitted.
Invoke-1EIdentityProviderAPI -Token <token> -Url https://dev-93204535.okta.com/api/v1/users/meFor Azure, you can do the same thing as shown below. Note that for Azure, the API address doesn't change for specific identity provider instances.
Invoke-1eIdentityProviderApi -token <token> -url https://graph.microsoft.com/v1.0/meCurrently only GET operations are supported by this cmdlet. Other verbs may be supported in a future release of the Toolkit. You can still call any API using simple PowerShell code and making these requests yourself. Refer to Using Bearer Tokens to access identity provider APIs.
You pass the object returned from Get-1EBearerToken directly in as a PowerShell variable to the -Token property, for example:
$token = Get-1EBearerToken .....
Invoke-1EIdentityProviderAPI -Token $token -Url .....Get-1EPlatformToken [-CertSubject <cert subject>|-CertThumbprint <cert thumbprint>|-Certificate <Certificate>] [-Decode]
This cmdlet retrieves a platform token. Platform tokens are used by internal platform components when sending or receiving requests between services.mThe certificate used must have a private key accessible to the account running the cmdlet and it must match the certificate that is installed on the platform to sign internal platform tokens.
The optional -Decode parameter returns the token as a PowerShell object.
You must call set-1Eserver first to define the platform server. If you are troubleshooting authentication issues, use the -BypassAuth parameter to that cmdlet. This will set the server but without attempting to authenticate.
This cmdlet is intended for test purposes. It is not generally useful in a production environment as the platform token signing certificate would normally never be available outside the platform itself.
Get-1EMetadataEndpoint
This cmdlet returns the metadata endpoint of the identity provider that is configured to be used by the 1E Platform (if any).
You must call set-1Eserver first to define the platform server. If you are troubleshooting authentication issues, use the -BypassAuth parameter to that cmdlet. This will set the server but without attempting to authenticate. You can then use the Get-1EMetadataEndpoint cmdlet to troubleshoot identity provider configuration issues.
Revoke-1EAuthToken
This cmdlet revokes the current authentication token (if any). You will need to re-authenticate after invoking this cmdlet if platform-neutral authentication was in use.
Get-1EJwt -AppId <appid> [ -Principal <principal> ] [ -MetadataEndpoint <metadataendpoint> ]
This cmdlet returns a JWT body for the specified AppId. If the optional principal parameter is specified, then the JWT contains a custom property for the requested principal.
If -MetadataEndpoint is not specified, then the user is assumed to have already connected to an instance of the 1E Platform using set-1Eserver, so the appropriate metadata endpoint will be retrieved from the platform.
Otherwise, if specified, it is used directly and this cmdlet will return a JWT without requiring any connection to the platform.
This cmdlet is intended for test purposes. The Jwt is not submitted to the identity provider.
Get-1ESignedJwt -AppId <appid> [ -Principal <principal> ] [ -MetadataEndpoint <metadataendpoint> ] [ -CertSubject <certsubject> | -CertThumbprint <certthumbprint> | -Certificate <certificate> ]
This cmdlet returns a signed base-64 encoded JWT (header plus body) that can be used to authenticate with the platform or that can be sent directly to an identity provider to obtain a bearer token.
If -MetadataEndpoint is not specified, then the user is assumed to have already connected to an instance of the 1E Platform using set-1Eserver, so the appropriate metadata endpoint will be retrieved from the platform.
Otherwise, if specified, it is used directly and this cmdlet will return a JWT without requiring any connection to the platform.
The signing certificate can be specified by either subject or thumbprint. In either case, it is assumed to be present in the local machine personal certificate store.
Alternatively, an already retrieved X509 certificate object can be used directly. In all cases, the certificate must contain a private key and the user's current account must have permission to read it.
The -Principal parameter, if specified, causes the JWT to include the optional Tachyon.Upn claim that specifies a principal. This is used by the platform when authenticating to determine a principal to map the returned internal token to if certificate mapping permits multiple principals. Otherwise, if the JWT is submitted directly to an identity provider, this claim is ignored.
This cmdlet is intended for test purposes. The signed Jwt is not submitted either to the platform or to any configured identity provider.
Get-1EJwtHdr -CertSubject <certsubject> | -Certificate <Certificate>
This cmdlet returns a JWT header for the specified certificate. You can specify either the subject of a certificate to be located in the localmachine\my store (Personal store) or an X509Certificate2 object which contains the certificate.
This cmdlet is intended for test purposes. The Jwt header is not submitted to the identity provider.
Get-1EVersion
This cmdlet returns the version of the currently configured platform server. An error is thrown if no server is configured.
Get-1EToolkitVersion
This cmdlet returns the version of the 1E PowerShell Toolkit.
Get-1EDefaultConsumer
This cmdlet returns the platform consumer that is used when communicating via the API. The default is Explorer.
Set-1EDefaultConsumer -Name <name>
This cmdlet sets the default platform consumer that is used when communicating via the API. An error is thrown if an invalid consumer is specified and the current default remains unchanged.
Get-1EComponentHealth
This cmdlet returns information about the status of each platform subsystem.
This cmdlet requires platform release 5.1 or later. It will throw an error if invoked against earlier releases because the API was not implemented in those releases.
Get-1EConsumer [-Id <id>] [-Name <name>]
This cmdlet returns the available platform Consumers and their properties. Currently, the 1E PowerShell Toolkit uses the Explorer consumer so that instructions and results invoked from the Toolkit are also visible in the UI.
If either the optional Id or Name parameters are supplied, then only the consumer whose Id or name matches the parameter value is returned.
Add-1EConsumer -Name <name> [ -MaxInstructions <max instruction count> ] [ -OffloadTargetUrl <url> ] [ -Disabled ]
This cmdlet adds a new consumer specified by name. The consumer is enabled by default unless the -Disabled switch is provided.
The default maximum instruction count is 100 unless overridden with the optional -MaxInstructions parameter.
The OffloadTargetUrl will be empty by default but can be overridden with the -OffloadTargetUrl parameter.
Update-1EConsumer -Id <id> [ -Name <name> ] [ -OffloadTargetUrl <url> ] [ -MaxInstructions <instruction count> ] [ -Enable ] [ -Disable ]
This cmdlet updates one or more properties of a consumer. To remove an existing offload target URL, you can specify an empty string for this parameter.
Remove-1EConsumer -Id <id> | -Name <name>
This cmdlet removes the consumer specified either by Id or name.
Get-1EDeviceTag
This cmdlet returns the available device tags (also referred to as custom properties or coverage tags) that have been defined on the platform server.
Device tags can be used in scope expressions to determine the target set of devices for instructions. Refer to Scope and filter expressions.
Get-1EDeviceTagValue -Id <id>|-Name <name>
This cmdlet returns the available values for a specified device tag Id or name.
Add-1EDeviceTag -Name <name> -Values <values>
This cmdlet adds a device tag with the specified name and an initial value set <values>. You can specify a single string for 'value' or an array, for example, @('value1','value2'....).
Once you have added a tag and an initial value, you use the Add-1EDeviceTagValue cmdlet to add further values or the Remove-1EDeviceTagValue cmdlet to remove values. A tag must have at least one associated value at any time.
Add-1EDeviceTagValue -Id <id>|-Name <name> -Value <value>
This cmdlet adds a new property value to the device tag whose Id is specified in the -Id parameter or whose name is specified in the -Name parameter.
An error is thrown if the device tag does not exist. Use add-1Edevicetag to create a tag.
Remove-1EDeviceTag -Id <id>|-Name <name>
This cmdlet removes the device tag specified by the -Id or -name parameter, along with all of its values.
Remove-1EDeviceTagValue -Id <id>|-Name <name> -Value <value>
This cmdlet removes the specified value from the list of device tag values. An error is thrown if the value does not exist or if it would be the last remaining value associated with the device tag.
The API actually permits all tag values to be deleted without removing the tag itself. However this is not supported by the UI, which does not expect to find a tag with zero values. Therefore, this cmdlet enforces that limitation by preventing you from deleting the last remaining value without deleting the tag itself.
Get-1EDeviceTagId -Name <name>
This cmdlet gets the tag id for the specified tag name.
Get-1EDeviceTagName -Id <id>
This cmdlet gets the tag name for the specified tag id.
Get-1ENotification [-Id <id>]
This cmdlet returns any notifications that are available for the current user. The optional Id parameter allows you to retrieve only notifications associated with a specific instruction.
Use the Get-1EApprovalNotification cmdlet to retrieve instruction approval notifications (that would be displayed in the UI on the notifications page).
Get-1EApprovalNotification
This cmdlet returns any notifications regarding instruction approval. This cmdlet returns notifications that are visible in the platform UI.
Get-1ESystemTopography
This cmdlet returns information about the physical system topography, that is, switches, cores, and so on.
Get-1ESystemStatistics
This cmdlet returns a summary of information about the system, as shown below.
Get-1ESLAComponentHealth
This cmdlet returns health status for the SLA subsystem, including component status and database connectivity checks.
Publish-1ESchedule -InstructionName <instruction name> ...
-TargetScope <scope>
-Schedule <schedule>
[-EvaluationCondition <condition>]
[-Task <task>]
[-StartDate <start date>]
[-EndDate <end date>]
[-StartTime <Start time>]
[-EndTime <end time>]
[-InstructionTtlMins <mins>]
[-ResponseTtlMins <mins>]
[-ConsumerCustomData <string>]
This cmdlet creates a new schedule. Optionally, you can specify a server-side task script to be run each time the schedule is triggered, after the associated instruction has been executed.
An instruction schedule creation operation requires workflow approval, whether or not the scheduled instruction is a question or an action. For more information on platform workflow, refer to Workflow management cmdlets.
To learn how to create a platform schedule and approve it, refer to Managing platform schedules.
|
Parameter |
Description |
|---|---|
|
InstructionName |
The name of the instruction to be scheduled. |
|
TargetScope |
The scope for the instruction. TargetScope is evaluated as dynamic scope. That is, unlike the default scope for an instruction invoked directly from the 1E PowerShell Toolkit, which evaluates to a set of currently-active devices, the scope is left as a target expression and evaluated when the scheduled instruction is actually invoked each time. This is equivalent to specifying dynamic scope when invoking a normal instruction from the 1E PowerShell Toolkit. |
|
Schedule |
The schedule options. Valid schedules are the following:
If the day is not specified for weekly or monthly schedules, it defaults to day 1, which is Sunday for weekly schedules or the first day of the month for monthly schedules. |
|
EvaluationCondition |
An optional evaluation condition that, if true, will cause the optional Task script to be run server-side. This parameter directly accepts an evaluation condition as an expression, for example, -EvaluationCondition "NumberOfRows > 20". |
|
Task |
The name of a task script to be run server-side. If an evaluation condition is specified, the task script is only run once the instruction specified in the schedule has returned all results, and the condition is evaluated to true. If no evaluation condition is specified, the task script is run once the instruction specified in the schedule has returned all results. For example, the evaluation condition specified above will cause the conditional action task script to be run if more than 20 rows were returned from the instruction when it is invoked. See the publish-1Econditionalaction cmdlet below for more information on task scripts. When you specify an evaluation condition, the appropriate API model parameters are set for you automatically. |
|
StartDate |
The date on which the schedule first becomes active. If not specified, today's date is used. |
|
EndDate |
The date on which the schedule ceases to be active. If not specified, the start date plus one day is used as the default. For scheduling periods longer than daily, these defaults will cause the schedule to be rejected with the error that no scheduled events would occur in the specified time period. Ensure that the end date is sufficiently later than the start date to accommodate the chosen schedule period. Both start and end dates are specified in the format YYYY-MM-DD. If a datetime is passed, the time period is ignored. |
|
StartTime |
For a schedule that triggers at most once in any day, it specifies the time of day when the schedule will trigger. For a schedule that triggers multiple times in a day, it specifies the time of day when the first trigger event will occur. |
|
EndTime |
For a schedule that triggers multiple times in a day, it specifies the time of day after which trigger events will no longer occur. When a one-time schedule is defined, if the start date is today, and the start time is not specified, it is set to one minute later than the current time. Start and end times are integer values. They are interpreted as HHMMSS, so the maximum value is 235959, which corresponds to 23:59:59. |
|
InstructionTtlMins |
The length of time the instruction will gather data for. The default is 60 minutes. Defining a schedule period less than the instructionttlmins value will cause an error. |
|
ResponseTtlMins |
The length of time the instruction results will remain available after the data collection phase has ended. The default is 60 minutes. |
|
ConsumerCustomData |
An arbitrary string (which could be encoded JSON) that will be available via the get-1Einstructionstatus cmdlet when the instruction becomes active. For example, you can pass the object @{Property1="Value1" , Property2 = "Value2"}. You can use this as a parameter-passing mechanism for conditional action tasks. |
Get-1ESchedule[-Id <id>]
This cmdlet returns all defined schedules or the schedule whose Id is specified.
Remove-1ESchedule -Id <id>
This cmdlet removes (deletes) the specified schedule.
This has no impact on any conditional action script (if any) associated with the schedule which will remain on the server until deleted.
Get-1EScheduleActivation -Id <id>
This cmdlet returns all activations of the specified schedule (if any).
Get-1EScheduleParam -Schedule <schedule>
This cmdlet returns the scheduling API parameters which would be required to implement the schedule defined.
Get-1EScheduleParam -Schedule "every 25 minutes"
Publish-1EConditionalAction -Path <script> [-Force]
This cmdlet publishes (uploads) the specified script. This script can be associated with one or more scheduled tasks. It is written in PowerShell and must be signed, with the code signing certificate being available on the platform server to verify the script. Refer to Signing PowerShell scripts.
To overwrite an existing script, use the -Force option.
This cmdlet does not verify that the script is signed or, if signed, that the signature is valid. The script will be uploaded to the server regardless.
Remove-1EConditionalAction -Name <name>
This cmdlet removes (deletes) the conditional action script whose name is specified. Note that if any scheduled tasks have been associated with this conditional action script, an error is thrown. These scheduled tasks will need to be removed or updated to remove the script reference before the conditional action can be removed.
Get-1EApplication [-Id <id>]
This cmdlet returns all installed platform applications or information about just the application whose Id is specified.
Get-1EConfiguration
This cmdlet returns information about the customer, UI Telemetry Key, and base consumer API endpoint.
Get-1EJwkFromCertificate -CertSubject <subject> | -CertThumbprint <thumbprint> | -Certificate <Certificate>
This cmdlet returns the public key portion of the specified thumbprint encoded as a JWK (Json Web Keyset). This format is required by some identity providers (for example, Okta) when uploading certificates to support the Client Assertion grant flow.
Get-1ECertificateFromKeyVault -KeyVaultUri -ManagedIdentity -CertName [ - Secret ] [ -AppId ] [[ -MetadataEndpoint ]
This cmdlet returns an X509Certificate2 object suitable for use with other cmdlets that accept certificates by querying the Azure Key Vault. For more details, refer to Set-1EServer <server name> ....
If a managed identity is not provided, then the secret, appid, and metadataendpoint parameters must be specified.
Secret: Defines a shared secret which is used to perform the oAuth grant flow to retrieve the certificate from the key vault.
AppId: The application which will be associated with the oAuth grant flow.
Metadataendpoint: The metadata endpoint of the Azure instance on which the application whose appid is specified is located.
For more information on oAuth access to the Azure Key Vault, refer to Accessing the Azure Key Vault using REST and oAuth.
Get-1EConnector [-Id <Id>]
This cmdlet returns all connectors or just the connector details for the Id specified.
Get-1EConnectorType
This cmdlet returns all available connector types and the associated metadata for those types.
Update-1EConnector -Id <id>
This cmdlet refreshes the connector specified by the Id. This cmdlet is intended for use when migrating an on-premise installation to a SaaS instance. It will throw an exception if run against a platform whose version is less than 8.2.
The cmdlet will only refresh connectors of type Tachyon and it will throw an exception otherwise.
When run, the credentials for the connector are updated, and the password property is set to NotApplicable. This causes the underlying SLA subsystem to refresh its database to ensure that legacy credentials are not used when a Tachyon connector is invoked. This is because versions 8.2 onwards use platform-neutral authentication and do not utilize the credentials that were stored in legacy instances of the platform to connect.
Get-1ECertificateFromStore [ -CertSubject <subject> ] | [ -CertThumbprint <thumbprint> ]
This cmdlet retrieves the specified certificate from either the local machine personal store (Windows) or the current user personal store (Linux) and returns it as an X509 certificate object.
Get-1EConfigurationSettings -Application <application>
This cmdlet retrieves the platform configuration settings for the specified application.
Get-1EConfigurationSetting -Application <application> -Setting <setting>
This cmdlet retrieves a specific platform configuration setting for the specified application.
Set-1EConfigurationSetting -Application <application> -Setting <setting> -Value <value>
This cmdlet sets a specific platform configuration setting for the specified application.
Get-1ELicenseInfo
This cmdlet returns licensing information for the platform. This cmdlet can be useful when troubleshooting platform issues since if the platform cannot retrieve licensing information, some parts of the platform will not function correctly.