Chat now with support
Chat with Support

Welcome, erwin customers to Quest Support Portal click here for for frequently asked questions regarding servicing your supported assets.

Quadrotech Nova Current - User Guide

Overviews Adoption Accelerator Delegation & Policy Control (DPC) Reporting TMS Settings About

Custom Powershell

The Custom PowerShell functionality in Nova 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.

 

info

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

oAzure AD

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.

info

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.

 

info

NOTE: In normal operation, a notification will be generated when the job completes.

 

Custom Powershell Additional Details

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.

info

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 AzureAD 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"

Delegated Administration

An administrator can authorize others within the organization to have specific delegated administrative rights. This article describes some ways rights might be delegated within an organization.

Managing Direct Reports

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 Office 365 for those sales managers. Here is how it looks:

Managers-and-employees

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:

Self-service-1

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:

Delegated-admin-within-OU

 

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.

·A delegated administrator can manage Microsoft Teams.

Delegating Administrative Rights

An administrator can authorize others within the organization to have specific delegated administrative rights. This article describes some ways rights might be delegated within an organization.

Managing direct reports

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 Office 365 for those sales managers. Here’s how it looks:

Managers-and-employees

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’s how it looks:

Self-service-1

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:

Delegated-admin-within-OU

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 Microsoft Teams.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating