The Custom PowerShell functionality allows almost any PowerShell scripts to be executed to perform custom tasks within your tenant organizations.
This accessibility of this function is dependent on the user's role:
·System Administrator and Account Administrator roles will have access to Refresh, Add, Edit, Delete and Run command functions.
·Autopilot Classic roles will be able to Refresh and Run command actions.
·Auth Policy admins will be able to delegate PowerShell commands to other users. Click here to see how to create an authorization policy to delegate custom PowerShell commands.
NOTE: Custom PowerShell scripts can run for up to 600 seconds (five minutes), after which the script will timeout. |
More details on the scripts, validation and parameters can be found here.
Creating a new custom script
Follow the steps below to add a new custom script:
1.In the left menu, select Manage > Custom PowerShell.
2.Click on Add'
3.Give the custom PowerShell script a meaningful name.
4.Select the online PowerShell-type that the script will run against. You can choose one of the following:
oExchange Online
oMicrosoft Entra ID
oMS Online
oMS Teams
oSharePoint
6.Enter the PowerShell script that should be executed.
7.Click on Validate. (You will need to correct any errors before the final step)
8.Save the script.
Here is an example script for setting a retention policy on a mailbox:
param( [Parameter(mandatory=$true)] $name, [Parameter(mandatory=$true)] $retentionPolicyName )
set-mailbox "$name" -RetentionPolicy "$retentionPolicyName"
To use this script, you would select Exchange Online' as the PowerShell type. After validating the script, you will see that two parameters were added to the bottom of the data entry page.
More details on the scripts, validation, parameters and so on, can be found here.
Editing or deleting existing custom script
To edit or delete a script follow these steps:
1.In the left menu, select
2.Manage > Custom PowerShell.
3.Locate the script you want to edit or delete, and select it.
4.Either:
oClick Edit, make desired changes, and click Save to apply all the edits.
oClick Delete and confirm the delete action.
Executing a script
To run a script follow these steps:
1.In the left menu, select
2.Manage > Custom PowerShell.
3.Locate the script you run and select it.
4.Click on Execute command'
5.You must specify:
§The tenant you wish to execute the script on
§Any required parameters, including applying authorization policies.
NOTES: ·You may need to scroll down the page in order to see the list of parameters. ·Applying an authorization policy parameter only applies to those with Autopilot Classic roles. |
6.Click on the Execute' button.
Nova will now submit a job for this script to executed against the selected tenant. The following section explains how to check if the script ran successfully.
Reviewing the execution of a script
To verify that a script ran, follow these steps:
To run a script follow these steps:
1.In the left menu, select
2.Manage > Jobs.
3.Locate the script you ran, and review the status column to see if the script ran successfully or if it generated an error.
You can filter the list of jobs on the job screen in order to make it easier to find the required information.
NOTE: In normal operation, a notification will be generated when the job completes. |
Delegated administration for custom PowerShell commands
A delegated administrator can also have access to execute custom PowerShell scripts. For this to occur, an administrator has to assign the delegated admin to an organizational unit containing a custom script commands within an authorization policy. These can be Meta-OUs, Tenant-OUs or regular OUs.
NOTE: As a delegated administrator, you are only allowed to run scripts you have been assigned to. You are forbidden to run any other custom script. |
Supported types
The Custom PowerShell command which will be executed must have a param (...) block. The entire command is parsed and validated for PowerShell 5. The command must be syntactically correct in order to pass validation.
The following is a list of the supported types:
PowerShell |
Field |
Notes |
---|---|---|
-none- |
Text |
|
[string] |
Text |
(1) |
[byte] |
Number |
(1) |
[sbyte] |
Number |
(1) |
[short] |
Number |
(1) |
[ushort] |
Number |
(1) |
[int] |
Number |
(1) |
[uint] |
Number |
(1) |
[ulong] |
Number |
(1) |
[float] |
Number |
(1) |
[double] |
Number |
(1) |
[decimal] |
String |
(1) |
[bool] |
Boolean |
(1) |
[switch] |
Boolean |
|
-other- |
String |
(1) Accepts CLR type name, eg System.String, System.UInt32, System.Boolean, etc
Recognized attributes
[Parameter]
·Mandatory is supported. Mandatory fields must be provided when user tries to execute script. Mandatory [bool] and [switch] parameters should be avoided. While most of values ($null, 1, "true", ...) can be converted to boolean value, user should use either [Parameter(Mandatory)] or [Parameter(Mandatory = $true)].
·ParameterSetName is not supported. Multiple parameter sets may cause script to be not executable.
·Other parameters properties are ignored.
[ValidateNotNullOrEmpty]
Parsing and saving
When a command is stored, the parser extracts known validation attributes and stores information in the parameter model. This information is then translated into DTO so the user interface can render the appropriate field.
The parser ignores validation attributes it can not recognize.
Here is example of parameters and corresponding extracted validation.
// param ($Foo)
{
"name": "Foo",
"isMandatory": false,
"validateNotNullOrEmpty": false,
...
}
// param([Parameter(Mandatory)] [ValidateNotNullOrEmpty] $Foo)
{
"name": "Foo",
"isMandatory": true,
"validateNotNullOrEmpty": true,
...
}
Triggering execution
The Custom PowerShell commands are execute from the Execute Command' button in the user interface.
Mandatory and required fields
Text fields
isMandatory |
validate Not Null Or Empty |
parameters value (execute request) |
request is valid |
Notes |
---|---|---|---|---|
false |
false |
{ } |
true |
|
false |
false |
{ Foo : } |
true |
|
false |
false |
{ Foo : null } |
true |
|
false |
false |
{ Foo : bar } |
true |
|
true |
false |
{ } |
false |
UI must send { Foo : } |
true |
false |
{ Foo : } |
true |
|
true |
false |
{ Foo : null } |
true |
This is acceptable but is preferred. |
true |
false |
{ Foo : bar } |
true |
|
false |
true |
{ } |
true |
|
false |
true |
{ Foo : } |
false |
|
false |
true |
{ Foo : null } |
false |
|
false |
true |
{ Foo : bar } |
true |
|
true |
true |
{ } |
false |
Field is required |
true |
true |
{ Foo : } |
false |
Field is required |
true |
true |
{ Foo : null } |
false |
Field is required |
true |
true |
{ Foo : bar } |
true |
Boolean fields
isMandatory |
parameters value (execute request) |
isValid |
Notes |
---|---|---|---|
false |
{ } |
true |
|
false |
{ Foo: false } |
true |
|
true |
{ } |
false |
|
true |
{ Foo : true } |
true |
Example scripts
Create a user, using the Microsoft Entra ID module:
param(
[Parameter(Mandatory=$true)] $displayname,
[Parameter(Mandatory=$true)] $givenName,
[Parameter(Mandatory=$true)] $surName,
[Parameter(Mandatory=$true)] $upn,
[Parameter(Mandatory=$true)] $usageLocation,
[Parameter(Mandatory=$true)] $nickname,
[Parameter(Mandatory=$true)] $password,
[Parameter(Mandatory=$true)] $skuname
)
$PasswordProfile = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile
$PasswordProfile.Password = "$password"
New-AzureADUser -DisplayName "$displayname" -GivenName "$givenName" -SurName "$surName" -UserPrincipalName $upn -MailNickName $nickname -PasswordProfile $PasswordProfile -AccountEnabled $true
Set-AzureADUser -ObjectID $upn -UsageLocation $usageLocation
# Create the objects we will need to add and remove licenses
$license = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicense
$licenses = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicenses
# Find the SkuID of the license we want to add e.g. Win10_VDA_E3
$license.SkuId = (Get-AzureADSubscribedSku | Where-Object -Property SkuPartNumber -Value "$skuname" -EQ).SkuID
# Set the Office license as the license we want to add in the $licenses object
$licenses.AddLicenses = $license
Set-AzureADUserLicense -ObjectId "$upn" -AssignedLicenses $licenses
Create a new Microsoft Team, with some specified channels:
param(
[Parameter(Mandatory=$true)] $TeamName,
[Parameter(Mandatory=$true)] $desc,
[Parameter(Mandatory=$true)] $TeamVisibility,
[Parameter(Mandatory=$true)] $channelName1,
[Parameter(Mandatory=$true)] $channelName2,
[Parameter(Mandatory=$true)] $channelName3
)
$group = New-Team -DisplayName "$TeamName" -Description "$desc" -visibility $TeamVisibility
New-TeamChannel -GroupId $group.GroupId -DisplayName "$channelName1"
New-TeamChannel -GroupId $group.GroupId -DisplayName "$channelName2"
New-TeamChannel -GroupId $group.GroupId -DisplayName "$channelName3"
An administrator can authorize others within the organization to have specific delegated administrative rights. This section describes some ways rights might be delegated within an organization.
Managing direct reports
For example, an administrator could give sales managers the ability to manage certain attributes and/or rights of the individual sales team members without any additional rights granted either on-premises or in Microsoft 365 for those sales managers. Here is how it looks:
Self service
An administrator might want to give certain users the ability to manage some of their own access or information. For example, some executives might be able to log in to Nova and grant themselves access to resources/information without calling the helpdesk to get access.
Similarly, you might configure a policy that enables all employees to use Nova to update some of their basic information (for example, their phone number and address). This is called the self service option, here is how it looks:
Delegated administration within an organizational unit
Finally, an administrator might want to set up someone within an organizational unit to manage access of others within that organizational unit. For example, you might have an organizational unit containing employees who work in a certain office location. You might assign administrative rights to the site manager or administrative assistant. It could look like this:
As you can see, Nova is highly customizable. In any of these examples, the administrator can specify which access rights managers/individuals/delegate administrators can assign to themselves and others.
Examples
Here are a few examples of delegated administration.
·A delegated administrator (maybe someone from the help desk) resets a user's password.
·A delegated administrator can manage out of office messages.
It is easy to reset a user password with Nova, here are the steps:
1.Locate the user in the Users tab under Manage.
2.Bring up more detailed information about the user by clicking on the user.
3.Click Authentication.
4.Click Reset password.
5.Enter the new password and optionally force the user to change their password at the next login.
6.Click Save.
Nova will perform the password reset on your behalf, and a notification will be generated when the job completes.
Take a look at how to do these steps in this quick video.
Nova gives the ability to set a user's out of office message, with the possibility to set different messages to internal and external users. To do this:
1.Go to the Manage tab, then click Mailboxes.
2.Locate the user you would like to set an out of office message to.
3.Click Automatic Replies.
4.Click Set Out of Office.
5.Click the drop down list, and select Scheduled.
6.Select the scheduled start and end date and time for the message.
7.Enter the internal and external messages you would like to send to recipients.
8.Click Save. This will then appear as a running job in the Jobs tab.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. 이용 약관 개인정보 보호정책 Cookie Preference Center