You may have been reading up on the Enterprise Mobility Suite by Microsoft. Especially now that Windows 10 has been released, it seems like everything is becoming easier and simpler for end users, managers and admins alike while Microsoft is really pushing the Anywhere, Anyplace, Anytime concept.
Let me state first off that I believe these advancements are incredible, and I really feel Microsoft is heading in the right direction, but there are quite a few ‘gotcha’s’ that you probably don’t know about that could hurt your implementation, they may not always apply to you.
In my opinion, as EMS currently stands as a suite, when used to manage Windows 10 laptops / tablets and desktops, is only suitable for very ‘light’ management situations unless there is an additional device management authority such as SCCM fully configured and implemented as Internet Facing for true device and application management.
I was recently asked to build a Powershell script to fully automate building up a server, including detailed configuration and installation of roles and other software.
Some of these actions required a reboot. After a reboot, the Powershell script had to restart itself. When running a script remotely, Workflows can be used, but when running the script locally I could not get this to work properly. Thus, I built a self-restarting script template that will run each phase as you configure it.
This self-resuming Powershell script writes its own run configuration to a Scheduled task that will run at boot time without user interaction, under the SYSTEM account. It will run all the commands you specify, reboot and resume when necessary, and unregister itself when it has completed.
This is awesome for, for example, building up Terminal Servers or Web Servers in a highly virtualized environment. Of course there are many orchestration tools available, and they may be better suited for this task, but those were not available when I was asked to code this.
Firstly, my Powershell scripts / sessions can now be secured using MFA, without having to rewrite my scripts, except those where I built the Credential object with preset credentials….but that’s old anyway.
Secondly, I can now finally manage Registered Devices with the same Module, allowing me to use these commands:
You can use either the owner’s UPN or the device ID with these commands.
Slowly but surely, the Office 365 dev team is adding reporting functionality to their platform, to the delight of admins and managers alike. For admins it means a lot less scripts to write, for managers it means knowing….stuff.
One report I missed was a report that tells me when users last logged on. Because if I have thousands of users, and they all consume licenses….I’d very much like to strip licenses from users that haven’t logged in since x amount of time.
Especially for companies with geographically dispersed users and inefficient exit procedures, this can save a lot of licensing costs over time.
My report was built in Powershell, and will check the last time the mailbox was accessed to determine the last logon date, this is not perfect, as I can image some organisations use specific licenses just for skype or dynamics, they will not benefit as much from this script, but in 99% of the times it should suffice 🙂
The script will list the user UPN, Name, Last Logon, Creation Date, Usage Location, Mailbox Size and Used Licenses.