Home› SMA
Options

PowerShell + Office 365 SKUs + Cireson License Class

John_LongJohn_Long Customer Advanced IT Monkey ✭✭✭
in SMA
Hey all,

Was doing some messing trying to synchronize Office 365 SKU's into the Cireson License object and came up with the following quick and dirty script. For per-user assignments, it will add the user object to the license assignment section.

Happy to take all feedback on board! :)

As usual with all things from the internet, review the script prior to testing in your playground.
In case you missed the above, it's quick; and dirty! :-)

PowerShell Requirements:
MSOnline
SMLets

Script Changes:
Change line 37 to include your UPN pattern
Change line 59 to your SCSM server name

Issues:
O365 module doesn't expose expiry dates on plans sadly.
Error checking could be more robust.

https://gist.github.com/anonymous/20a6354cdcc884c6b3b3f3c2bb4efe79#file-cireson-o365-ps1

John


Comments

  • Options
    Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    Where are you running this from? I have almost the IDENTICAL script sitting in SMA and it doesn't work because...

    https://community.cireson.com/discussion/602/azure-active-directory-powershell-in-sma#latest

  • Options
    John_LongJohn_Long Customer Advanced IT Monkey ✭✭✭
    Running it from PowerShell ISE at the moment. Haven't yet brought it across to SMA!
  • Options
    John_LongJohn_Long Customer Advanced IT Monkey ✭✭✭
    OK @Adam_Dzyacky , I tried your code snippet from the previous post on my SMA server and it ran without issue. Anything you'd like me to test or find for you?

    The MSOL Sign-In Assistant is installed on my SMA server and it looks to be v1.0.0 of the module.
  • Options
    John_LongJohn_Long Customer Advanced IT Monkey ✭✭✭
    On a related note, would love to hear thoughts on how to handle removals from the assigned user list. It seems a little heavy handed to remove all users from all License objects prior to update actions. Comparing O365 UPNs to SCSM System.Domain.Users seems a little problematic.
  • Options
    Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    John_Long said:
    OK @Adam_Dzyacky , I tried your code snippet from the previous post on my SMA server and it ran without issue. Anything you'd like me to test or find for you?

    The MSOL Sign-In Assistant is installed on my SMA server and it looks to be v1.0.0 of the module.
    1. WHAT - but seriously, congrats! I'm rather jealous.
    2. Yes please! Could you try to invoke this against your SCSM WF server from SMA? (i.e. inlinescript against your WF server).

    Not sure what your plan was, but I was thinking it simplest to invoke from WF server where SMlets and a mgmt server will already be to write into AM.
  • Options
    John_LongJohn_Long Customer Advanced IT Monkey ✭✭✭
    @Adam_Dzyacky That's exactly what I did. Took your runbook and and plugged it into SMA as workflow testMSOL { ... }.

    Published it then hit start!

    On the update problem, it's creating the objects and assigning memberships without issue. What I'm querying is the best way to handle cases where users have licensed removed via O365 Portal. For now, in DEV, I'm just scrubbing all the user relationships and repopulating but it's not elegant!

    For reference sake here's a link to the DEV workflow I'm using in my SMA server.
    I think we're doing the exact same thing though.

    Change line 4 to the SCSM server.
    Change line 5 to reflect valid O365 credentials to query license state.

    https://gist.github.com/anonymous/2a55a41c250c161767e06f8742b4cf8a#file-msol-synclicenses-ps1

  • Options
    Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited September 2016
    WAIT! I see what you've done differently, you aren't inline scripting to your WF server! The inlinescript you leverage is running on your one of your SMA boxes and not invoking on the WF server. From the looks of how you're using SMlets (without a computer name) I'm going to guess you deployed SMlets across your SMA farm, and then modified the registry, copied the SCSM DLLS, and pointed to your WF server so you don't have to call -computername on the cmd-lets then? Whichever the case, I just tried peforming MSOL cmds directly on an SMA host (like you have) and that works. If you want to point this solution out on my thread I'd be more than eager to give you credit/mark as the answer.


    With respect to your update/delete processes, I'm thinking something along the lines of leveraging Compare-Object. Now that I have this working I should be able to participate in this conversation!
  • Options
    John_LongJohn_Long Customer Advanced IT Monkey ✭✭✭
    Ah yeah. I figured it was easier to do it that way rather than 'session' into the server itself.

    I was hoping to use compare-object too but can't distill it down into a nice enough structure to compare! I'm sure we'll figure something out! :)
  • Options
    Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited September 2016
    After a day, I have my own version of a tentative working pass. When I compare what I have to what you have, I may have really over-engineered it...alright I probably did. Certainly willing to share the second I can generalize it a bit more. Whichever the case:

    • I'm also conceptually struggling about how to deal with updating users without checking out each one for changes leveraging compare-object because of the whole "best way to distill them down to compare". I guess this is another way of saying, I'm now eating my own words/suggestion :)
    • With regards to the checking each one, the very first problem that came to mind is how SCSM deals with AD name changes in that it creates wholly new User Objects in the CMDB. Which means the matching criteria for this is going to have be something super special to perform this reliably and avoid "double licensing". This alone really makes me struggle with intelligently leveraging compare-object since the objects could be different each nightly SMA pass. It could be done in a single script, but in terms of just breaking this out it almost feels like two jobs. One to perform the initial sync, another to figure out if the User Account in SCSM hasn't been updated in more than X days and then remove all Assets regardless. This second job has less to do with our current situation and more to do with the larger picture of how SCSM deals with renames. I know there is a way to re-associate all relationship from one account to another, but that process is too on-demand that makes me question how if at all it  could be integrated into what we're trying to do.
    • I ended up creating a wholly separate job to pull licenses and their respective statistics. This is more of a personal preference than anything so it can be called independent of this process. And by virtue of its independence could be called inline with this process.
    • I leveraged OU and UPN matching so as to target a specific group of CMDB users (instead of all), I wrote a really quick function that converts the AD distinguished name to the SCSM OU name since they aren't identical after import (i.e. their just missing "OU=").
Sign In or Register to comment.