Jump to content

Recommended Posts

Posted

I have a script I'm writing to correct the Office365 users as lots of them have imported 'wrong' (accounts sporadically have onmicrosoft emails instead of our own, no location, no license info, or any combination thereof) and the parts of the script that correct the email/login name and the location work just fine. Which is awesome. However, a bit of a snag with licenses.

 

Here's the offending piece of code:

ForEach ($Account in (Get-MSOLUser -All)) { 									# Check all users
$User = ($Account.UserPrincipalName)										# Strip out login name.
if ($Account.IsLicensed -eq $false) {										# If account has no license
	if ($PupilList -contains ($Account.UserPrincipalName -replace "@[color="#FF0000"]schooldomain[/color].net", "")) {			# If account is a pupil account
		Set-MsolUserLicense -UserPrincipalName $User -AddLicenses [color="#FF0000"]LICENSENAME[/color]_STUDENT					# Grant student license
	}
	if ($PupilList -contains ($Account.UserPrincipalName -replace "@[color="#FF0000"]schooldomain[/color].net", "")) {			# If account is a staff account
		Set-MsolUserLicense -UserPrincipalName $User -AddLicenses [color="#FF0000"]LICENSENAME[/color]_FACULTY					# Grant faculty license
	}
}
}

 

So, this loop is called after all incorrect users have had their UserPrincipalName changed and their location set, so all users by this point are @schooldomain.net. UserLocation is required to be set before licenses can be activated and this has already been set earlier by the script, too.

This section of the script is a separate loop to the UserLocation and UserPrincipalName modifying loop, as earlier in the script their UserPrincipleName may have changed.

The script is written to only modify users who have their .IsLicensed property as false so I should only be applying licenses to accounts that do not yet have one.

 

I have obtained our license names via Get-MSOLAccountSku | Format-Table -AutoSize so I'm definitely using the right licenses.

 

However, I get this error:

LicenseError.png

 

Now given that I've specified no license, I can't see why on earth this would happen, and the error code is completely unhelpful. The users have no license at all, so how is there a conflict? Confused!

Has anybody given powershell administration of Office365 a bash and able to point me the right way?

 

(Edit: Sorry for the tag @school!)

Posted
What happens if you try assigning the license to a user manually? Does $account.licenses return anything? Are you sure your logic for determining whether the user is a staff member or a pupil is working correctly? (e.g. so it's not trying to add both faculty and student licenses). I noticed that your code checked $PupilList when checking both staff and pupils... tho you have of course also obfuscated the school domain etc. so that might not be the case in your actual code.
Posted (edited)
Are you sure your logic for determining whether the user is a staff member or a pupil is working correctly? (e.g. so it's not trying to add both faculty and student licenses). I noticed that your code checked $PupilList when checking both staff and pupils... tho you have of course also obfuscated the school domain etc. so that might not be the case in your actual code.

 

That would be the best place to start. I've got a similar script which I'll have a look at and see how I handled the logic for checking licenses. I vaguely recall being able to filter on the original Get-MsolUser query but if not then you could pipe that to Where-object and check for the isLiscenced there and that should just return the data you need.

 

Edit: I used the get-msoluser - all | where { $_.isLicenced -eq "False"} way and it worked fine. Probably worth just running it from command line or ISE to test what data you get back to ensure its right.

Edited by halbaradkenafin
Posted

Staff members are in one OU, pupils are in another (strictly speaking, 5 others, one for each year group).. $StaffList is simply Get-ADUser OU=STAFF*, and Pupils are ForEach $OU in (OU=Year7-11)*.

 

I can try using Where-Object on the Get-MSOLUser and see where that gets me. I don't see how, if nothing else, it could end up any worse. I do know that $_.IsLicensed -eq $false works, though, as I tested that on its own.

 

* I can get the proper code tomorrow

Posted

It might be worth putting in a Write-Host $User before the Set-msoluserlicense so you can see what it's trying to use.

 

I'd probably try running it in the ISE as that will keep whatever variables you've set with their last value so you can run the script, hit ctrl+c (or the stop button) after a few errors and then check each variable to ensure its the value you'd expect.

Posted (edited)

Okay, the lists are generated with this chunk of code:

foreach ($User in (Get-ADuser -Searchbase "OU=School Staff,OU=Staff,OU=REDACTED,DC=REDACTED,DC=Local" -Filter {(Enabled -eq $True)})) { 	# For each user in School Staff OU
[Array]$StaffList += ((Get-ADUser $User).SAMAccountName)											# Add them to the StaffList array
}
ForEach ($OU in (Get-ADOrganizationalUnit -Filter * | Where-Object {$_.DistinguishedName -imatch "[\d]{4,} Intake"}).DistinguishedName) {	# For each OU that contains the string "[4 numbers] Intake" in its name
ForEach ($User in (Get-ADuser -Searchbase $OU -Filter {(Enabled -eq $True)})) {									# Get list of users contained within that are enabled
	[Array]$PupilList += ((Get-ADUser $User).SAMAccountName)											# Add them to the PupilList array
}
}

 

I can confirm this code generates the expected output, a list of all the usernames of all of our staff members. Emails for Office365 are ADusername @schoolname.net, which is why the list check strips out the @schoolname.net part (-replace "@...", "") and compares them to the lists. If it's in $PupilList it applies STUDENT license, if it's in $StaffList it applies the FACULTY license..

 

At least that's the idea.

 

Edit: As for it looking at PupilList both times, you're right, that was an oversight and it should be checking against $StaffList, but I wouldn't think that would cause the problem, as it would check if the user (in this case a member of staff) was in PupilList, see that it wasn't, and thus not try to apply the license.

$Account.UserPrincipleName is the Office365 account ([email protected])

 

Further edit: Making the second $PupilList correctly read $StaffList (feel like a damn fool for missing that >.<) has assigned all the staff members the correct license, so the code is correct. It's not thrown up any errors this time, so now I need to investigate which users have what licenses (as some were applied automatically)

Edited by Garacesh
Posted
I'd definitely try putting in a Write-Host $User before each Set-MsolUserlicense to check what is being assigned to that variable, then looking up a few of them to make sure they don't have a license already.
Posted (edited)

Progress!!

 

Script wasn't taking too kindly to "$Account.UserPrincipalName -replace" (perhaps it was trying to modify the actual UPN rather than just comparing the string?) so swapping that to $User worked!

Combined with checks for the invalid licenses (and -RemoveLicenses if a user has them..) I now have over 130 correctly applied staff licenses, over 1,000 correctly applied student licenses and zero incorrectly applied licenses.

 

I do, however, have 16 users that aren't licensed for some odd reason.. Time to delve into it and try to figure out why..

 

Edit: The ones that haven't gone in are either A) In an OU I haven't specified, B) Disabled accounts ($StaffList and $PupilList only grab enabled accounts.. No sense giving a kid a license if they're not here anymore, no?) or C) accounts where the UserPrincipalName is wrong so my script hasn't found a match.

 

C) is clearly something that needs to be fixed. Mostly this is due to female members of staff getting married and changing their name.

 

Consider Jane Bloggs becoming Jane Johnson. I have checked every single possible attribute of the user (as supplied by TechNet).. The only things that bear any resemblance to her name are DistinguishedName, Name, SamAccountName, Surname and UserPrincipalName.. All of which are referencing her new name.. Yet the Office365 email address has generated BloggsJ@ instead of JohnsonJ@.. Aaargh! Where on earth is it getting its name data from?!

Edited by Garacesh

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...