• State Verified Answer
  • Replies 13 replies
  • Subscribers 62 subscribers
  • Views 994 views
  • Users 0 members are here
Options
Related

How to check if an account is licenced after backsync following update to 8.1.3

charleneforbes
5 months ago

Hi,

I've recently updated to 8.1.3 and I'm having trouble with one of the custom scripts since it uses a newer version of powershell.  We have a hybrid setup and when we create users we aren't creating a mailbox.  Instead Exchange online is creating a mailbox when Azure syncs with the cloud.  Then when the backsync happens Active Roles checks that accounts have a icence assigned and then sets a custom attribute we created (edsvaRemoteMailboxCreation, bad name tbh), which then runs another script that adds the exchange attributes we want.  The second part is working fine, but since we updated the licence check isn't working properly.

Old script - 

$MSOLSession = Connect-msolservice -Credential $credential
$UserPN = $DirObj.get("UserPrincipalName")
$User = Get-MsolUser -userprincipalname $UserPN
if ($User.islicensed -eq $true)
{
$user = ($user.userprincipalname)
Set-QADUser $User -proxy -objectAttributes @{edsvaRemoteMailboxCreation=$true}
}
}

Initially after update I was getting an error on the first line, so I replaced that with:

$MSOLSession = Connect-ExchangeOnline -Credential $credential

I can run this script manually with powershell and it works but the new Active Roles doesn't like it when running as part of a workflow.  In Change history I get an error:

  • At line: 6 char:16. Could not load type 'System.IdentityModel.Tokens.JwtSecurityToken' from assembly 'System.IdentityModel.Tokens.Jwt, Version=6.22.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

I had a play with it and changed the script to use the Assigned licenses attribute instead, coming up with this:

$Licence = get-qaduser -proxy $UserPN -IncludedProperties edsaAzureUserAssignedLicenses,edsvaAzureObjectID | select edsaAzureUserAssignedLicenses
if ($Licence ="*disabledplans*")
{
Set-QADUser $UserPN -proxy -objectAttributes @{edsvaRemoteMailboxCreation=$true}
}
}

That seemed to work perfectly until I thought to check what it would do on someone who doesn't have a license. It makes the attribute true even if the AssignedLicenses attribute is blank!  Is this something anyone else has tried to do or do you have any suggestions please?

Thanks

Charlene

  • 0 5 months ago

    Hi  

    I'm not sure if you copied and pasted from your script, however this bit might be your issue, as you're assigning the value "*disabledplans*" to $License instead of evaluating it (= in place of -eq).

    if ($Licence ="*disabledplans*")

    I believe it should read

    if ($Licence -contains "disabledplans")

    Hope this helps.

    Stu

  • 0 5 months ago

    I believe the fault lies in your Connect-ExchangeOnline.

    You need to set it up to use a certificate / app combination.

    Here's an example from the Msft Documentation:

    Connect-ExchangeOnline -CertificateThumbPrint "012THISISADEMOTHUMBPRINT" -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"

    As it sits right now, it will be trying to connect using Basic Auth which is a no-no now - that's likely the source of your error.

  • 0 5 months ago

      You really should consider using group-based licensing for your Office 365 users as programmatic manipulation of direct licensing is very clumsy.  Whether you drive it from on-prem sourced groups or Cloud-only, it dovetails very nicely with AR driven provisioning.

  • 0 5 months ago in reply to JohnnyQuest

    Hi,   and  

    Thanks for the suggestions. Stu, your correction didn't cause an error, but it didn't complete the script either so I'm not sure where that went wrong. I'd tried using not $null before but that didn't work.

    Johnny, I missed a line from the start, we've been feeding in the login details via a clixml file since we started that still worked even after a previous update that stopped Basic Auth, at least for now.  I'll have a look at your method though, I did notice that to connect to Azure needed a certificate key this time that it didn't before so that may well be a smoother way of doing it.  

    Regarding group based licensing, we already do assign licenses via groups, which then assign the license in Azure when it syncs with ADConnect.  The issue with creating a mailbox in EXO is it doesn't add the required external forwarding email address for some reason so this workflow was created to compensate for that.  It was set up to add the attributes after the backsync, but only after checking the account actually has a license to allow for cases when they run out so the user doesn't get a mailbox.  The whole thing was set up by another team months before we started using Active Roles; before that the mailboxes were being created on on-prem exchange and then migrated up by the exchange admin team but this workflow negates that requirement.

  • 0 5 months ago in reply to charleneforbes

    Some food for thought on the licensing side of things: you may recall that there was/is an IsLicensed property returned by the msol commands. I don't have the graph property set memorized (yet). LOL But I imagine that there is something similar in there. That would allow you to detect a licensed state of the object.

  • 0 5 months ago in reply to JohnnyQuest

    Aye, if I can't get this method to work using Graph will probably be my next option. I'm going on leave for two weeks so don't want to change anything too drastic right now lol.  At the moment the script works as long as the licenses don't run out (knock on wood)

  • 0 5 months ago

    If you are performing this evaluation in the Active Roles Administration Service after a user has been Azure-enabled, you don't need to connect to Azure or Exchange Online in order to check if the license was properly applied. Active Roles queries the value for you via the Graph API, you just have to get it from Active Roles.

    I checked the edsaAzureUserAssignedLicenses attribute of an enabled and licensed user in order to see what the SKU GUID was that I was interested in, and then I was able to successfully check this using this query:

    $t = (Get-qaduser azure.enable01 -IncludedProperties edsvaAzureObjectID,edsaAzureUserPrincipalName,edsaAzureUserAssignedLicenses -proxy).edsaAzureUserAssignedLicenses

$licence = $t | ConvertFrom-Json

If($licence.skuid -eq "6fd2c87f-b296-42f0-b197-1e91e994b900")
{$TRUE}
else{$FALSE}

    If the license was present, even if it was one among many, the above evaluation spits out TRUE. If that specific SKU was not assigned, the evaluation was always FALSE.

    I hope that this helps!

  • 0 1 month ago in reply to Terrance.Crombie

    Hey Terrance,

    Any reason why I cant pull this attribute, edsaAzureUserAssignedLicenses,  from a script used in a workflow?

    I have tried these commands and cannot store the value to a variable for properly check always empty..  They all work fine at a command prompt.
    $User = $Workflow.SavedObjectProperties("Store SAM").get("samaccountname")


    #$tgtUserLic = (Get-qaduser mydomain\$User -IncludedProperties edsvaAzureObjectID,edsaAzureUserPrincipalName,edsaAzureUserAssignedLicenses -proxy).edsaAzureUserAssignedLicenses


    $tgtUser = Get-qaduser -proxy -identity mydomain\$User -IncludeallProperties
    $tgtUserLic = $tgtUser.edsaAzureUserAssignedLicenses

    $tgtUser = (Get-qaduser mydomain\$User -proxy -DontUseDefaultIncludedProperties).DN
    $tgtUserEntry = [ADSI]"EDMS://$tgtUser"
    $tgtUserLic = $tgtUserEntry.properties.edsaAzureUserAssignedLicenses