Tchater maintenant avec le support
Tchattez avec un ingénieur du support

Quadrotech Nova Current - User Guide

Adoption Accelerator Delegation & Policy Control Reporting Tenant Management System Settings About

Device compliance policies

You are able to add actions to Microsoft Intune configuration policies to your user's mobile devices. For DPC users, this is helpful if you need to modify devices and applications of users you are allowed to manage. The devices screen can be found within the Nova Dashboard by clicking Manage, then Devices.

Actions include:

·Refresh: this refreshes the list of devices in the tenant.

·Retire: if the device is no longer in use, you can retire it.

·Wipe: you can remote wipe devices immediately.

·Remote Lock: you can remotely lock devices immediately.

·Sync: Sync your device to get its most up to date information.

·Reboot: instantly reboot a device.

 

To show more details for your device, click on its name. Here, you will find several more tabs, including:

·Detail: this gives additional information of the device, including manufacturer, model, last sync date type and encryption state.

·Owner: this gives detail on the owner of the device, including email and the tenant the user is in.

·Users: this includes a list of users assigned to the device.

·Group Membership: if the device is part of a group, they will be listed here.

Also on this Device Detail page, you have the opportunity to remove the passcode (for iOS), and reset passcode (Android 7+ versions only).

License policies

License Policies in Nova give an administrator (or delegated administrator) the ability to assign/remove licenses, as needed, all from within Nova. Plus, Nova gives visibility into exactly how many licenses are used and how many are available.

 

The Nova license policies and reports provide:

·The ability to apply licenses according to what has been budgeted and what is required for a specific role

·The ability to show and hide particular licenses to include (or exclude) them from the report page shown above.

·Accurate license intelligence when it comes time for budgeting and Office 365 renewal.

·Delegated license management activities

Similar to other Nova policies, with a license policy you specify who can assign what licenses within a tenant or group. For example, a license policy might enable the Director of Engineering to manage Azure DevOps licenses assigned to users within the Engineering virtual organizational unit.

You can get really granular and specify which workloads from a license you want users to get. For example, if your organization does not use Yammer, you can remove that workload, if desired, before assigning an E5 license to someone. You can also specify how many of a particular license delegated administrators can assign.

To set up a license policy

1.In Nova, go to Manage administration > License policies.

2.Click Add.

3.Enter a Name for the policy.

4.In the Assignment section, with the Delegate to tab selected, click Add.

5.Select user(s) to whom you will delegate the ability to assign licenses according to the policy, and then click Add.

6.Select the Managed objects tab, and then click Add.

7.Use the Select type drop-down menu to choose whether the licenses can be applied to certain users, groups, and/or organizational units.

8.Locate any users/groups/organizational units containing users to which the licenses can be assigned, select them, and click Add.

9.Select the Licenses tab, and then click Add.

10.Select the tenant containing licenses you will add to the policy.

11.Select the licenses (and specify the maximum number of licenses) and workloads you want those delegated the policy to be able to assign, and then click Add.

After completing these steps, your policy is configured and the user(s) who are delegated the license policy can assign licenses to users specified in the policy.

To hide licenses

You can hide selected licenses from the licenses report, if desired, by clicking the Hide Licenses button.

 
You can also how/hide any hidden licenses by using the toggle option located in the top left of the list.

Custom Powershell

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.

 

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.

 

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

Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation