Office 365 User Manager

Before you get started

You will need two different packages from Microsoft before going any further. Without these packages you can not open Power Shell sessions with Office 365. Download and install each item highlighted for your system type.

Azure AD Module for Windows PowerShell

Once you have modules installed on you PC we need to copy the ADModules folder on your PC to the Azure AD Modules directory under C:\Program Files.

Launch a DOS shell in administator mode then copy the following commands into the DOS Shell on Windows to perform the copy of the modules. Copy each line allowing for a space in the middle.

xcopy /E /C /Q /R /Y "C:\Windows\System32\WindowsPowerShell\v1.0\Modules\MSOnline" 

"C:\Program Files\Windows Azure Active Directory\Powershell\MSOnline\"

This will copy the module to the correct directory for you so you can now execute Power Shell commands on your PC for Office 365 User Manager. If the files are not in the correct place the plugin will pop up a warning when you launch it. You will need to have the "L:\" mapped to the LTShare on your LabTech server. The plugin uses this location to launch the power shell Office365 command script. If the mapping cannot be made to the server you can create a drive with the letter L:\ assigned (USB stick or Disk partition). Place the same folder structure that the scripts folder has on the LTShare(L:/Transfers/Scripts/Office365/Office365Plugin.ps1). This will allow the plugin to see the command script and you will be able to execute the power shell cmdlets.

How it works

The simple answer is, the plugin uses Windows Power Shell and the Sign-In Assistant along with the Azure AD Module to remote execute Power Shell script-lets that make changes to users in Office 365.

The PC being used by the support personal will be performing several Power Shell tasks, these tasks are launched into a Power Shell window on the desktop of the support personal PC. The Power Shell window tries to make a connection out across the Internet to Microsoft Online Servers then negotiates a secure session to pass our cmdlets along to Office365 Active Directory. This process takes sometime, based on several factors like Internet speeds and load on Microsoft servers that may cause this connection to take several minutes to establish. During this time you should see the shell loading modules from Office 365.

Once the modules are loaded and the sessions connection complete we pass over the cmdlets and the information needed to complete the function the user requested. Afterwards we pause the Power Shell Window so you can read any returned information, warnings or errors, select [Enter] to close the windows.

Do Not Close Power Shell Windows before the Return Pause, this will cause you to cancel the current function.

Warning - If you are in hybrid mode and are using Dir-SYNC to synchronize a On-Premise Active Directory with Office365 then many of the tools in the plugin will fail for you. Things like updating a users password can only be done from the On-Premise AD servers. Office 365 will deny the request to change Active Directory information on users.

Data Collection

Before any data collection can take place you need to configure a few things. The very first thing you should do after of course importing everything, locating the scripts and making sure they are inside the Office365 scripts folder is to set the Admin Account for Office365 in LabTech.

Select the client you have an Office 365 Admin account for and open the Client Console, under the Passwords tab you will need to add 1 Office365 Account with the title being Office365, the Use Name being the Admin Account and the password being the current password for the admin account.

The plugin uses LabTech scripts to collect data about each client that has Office 365 accounts. You need to select 1 PC (Server or WorkStation) that is 64 bit and running a minimum of PowerShell 2.0. The Script looks for a Vista class system or higher to execute against, if you have no systems at a clients office that can manage this then you can edit the script and adjust the requirements but you do this at your own risk.

Once you have a PC picked out for each client then you will need to execute the Install AD Module for PowerShell script once against that system and monitor the scripts log tab on that system for failures in the installs. If all went well then the system is now marked as a Windows Azure Active Directory Modules Installed system. You can verify this by opening the system console and selecting the Info tab and on the Default sub tab you should have the check box checked for Windows Azure Active Directory Modules Installed.

You only need one system with this box checked, even if you have installed the modules on several systems make sure only one system has the check box checked at any given time. The Office 365 Data Collector script uses this setting to determine what system to runt the data collection on. If you have 2 or more systems checked at the same time then the script will run on each system duplicating the effort of populating the database with current information. This is not necessarily going to cause any issues but is duplicated efforts so be mindful of the systems you selected.

Along with scripts we also include a Group and a Search that is used to hold the scheduling of the Office 365 Data Collector script. The Group uses the search to locate systems with the Windows Azure Active Directory Modules Installed check box checked. The Group's scheduled scripts tab holds the script schedule. The script should be executed every 4 hours during business or support hours to keep the database up to date on the users and mailbox stats.

Now if we have all the pieces in place we should start to see data in our Office365 User Manager once the Office 365 Data Collector completes the first collection. You can execute the data collector script against your client system any time you like so you may choose to kick off a scan before the scheduled time.