Freigeben über

O365_Logon Module

  • Artikel

I created this PowerShell module to help O365 Administrators sign into the their online tenant services using simple verb-noun single command lets (cmdlets). While the general O365 PowerShell (PS) sign-in process is straight forward by itself, there are several lines of PS code that need to be combined and executed each and every logon attempt. This module is designed to help streamline the process of signing into O365 and specific modules that administrators often use. Visit the MS Script Center to get the O365_Logon Module download.

The current O365 components in this module to sign into are:

  • Compliance Center Online (CCO)
  • Exchange Online (EXO)
  • SharePoint Online (SPO)
  • Skype for Business Online (SfbO)
  • All four components (O365)

All five noun options have both a ‘Connect’ and ‘Disconnect’ verb available.

Connect-CCO – connect to the online Compliance Center
Connect-EXO – connect to Exchange online
Connect-SPO – connect to SharePoint Online
Connect-SfbO – connect to Skype for Business Online
Connect-O365 – connect to all four services with one cmdlet

Disconnect-CCO – disconnects from the online Compliance Center
Disconnect-EXO – disconnects from Exchange online
Disconnect-SPO – disconnects from SharePoint online
Disconnect-SfbO – disconnects from Skype for Business Online
Disconnect-O365 – disconnects from all four services

During the disconnects, the PSSessions are disconnected from the online tenant and the user variable credentials are nullified. Some modules, like the MSOnline module, cannot be currently disconnected without closing the existing PS session. Each of underlining O365 services PS connection scripts are listed on this technet page.

Also included in this module is a Request-Credential cmdlet. This allows you to request a new credential pop-up in case you incorrectly put in the wrong credentials. The module can’t detect good/bad credentials, but there is full logic in place to confirm if you successfully get logged onto a specific O365 service or not. There are cmdlets that call out and present a result from the tenant to display confirmation of actual connections to O365.

You must have the following pre-requisites already installed.

  • .Net 4.5.2 (This is a required update for your OS)
  • One of the following Windows Management Frameworks, which is the PowerShell version on your client computer. This module only requires PS version 3.0 or higher and no update is needed if you already have PS 3.0 or higher installed:

This module does NOT check for these installs. If you do attempt to use a cmdlet without the proper module(s) installed, PowerShell will error out and tell you what is missing. I have created another PowerShell script, O365_Installs_Connections.ps1, that will help with the installations of all of the requirements for this module to fully function, including a blog post of how to use the script.

SharePoint example with missing module:

I’ve also had issues where my O365 tenant was not fully functional and resulted in similar ‘red’ errors all over PS when logging in. So if this module was working and is now having an issue, log into your O365 admin portal and confirm that services are reporting ‘no issues’.

How to install this module

I know not everyone installs PowerShell modules often, or ever. A module install is extremely easy. Attached to this blog post is the O365_Logon.zip file, or download the zip file from the MS Script Center. You can also use the O365_Installs_Connections.ps1 script to perform the install, however, all you need is to copy/paste the O365_Logon folder into one of the following locations:

  • %Windir%\System32\WindowsPowerShell\v1.0\Modules
  • %UserProfile%\Documents\WindowsPowerShell\Modules
  • %ProgramFiles%\WindowsPowerShell\Modules

How to use this module

Once this module is installed, you can set the execution policy to either Remote Signed or Unrestricted.

Set-ExecutionPolicy RemoteSigned

Launch Windows PowerShell (‘Run as Administrator’ not required) and type in Connect-EXO. Tab complete also works, so you can tab through any ‘connect’ verb cmdlets on your system. Usually there are not too many ‘connect’ verb options already installed on your client machine.

When you hit the enter key, up comes the credential prompt that also has the message that you need to use your O365 SMTP address account information:

Once you are logged in, a message also appears confirming that you have access to your online tenant. There is logic built into each cmdlet to call out to O365 and present the results.

If the results are not returned correctly, an error message is displayed that you are not connected to the remote session.

 

Disconnects

Also included are disconnect verbs in this module. This helps in ensuring that your sessions are disconnected. You can also just simply close the current PS Window to close all of your connected sessions.

Request-Credential

As I was testing, I sometimes typed in the wrong user name and/or password information. The sessions then errored out and I would have to close the entire PS window to start over. So I made the logon process easier by adding this Request-Credential cmdlet.

You simply use this cmdlet, up pops the credential screen, put in a proper user name and password, then hit ‘OK’. You can then choose which O365 service(s) to connect to. The credentials are saved as a variable and then can be passed into any/all of the connection options.

With bad credentials, if you just try another connect, the current credentials are not reset. I left it this way so that if you’re connected to EXO and then need to connect to SPO for example, the credentials are still available in the current PS session. If you need to flush your credentials, simply disconnect or close the PS window. This is the same process if you’d run the logon code manually.

Conclusion

I hope you find this O365 Logon Module helpful. It should assist you in making your logon to O365 experience within PowerShell quicker and much easier. Thank you.

Update (12/7/15)

I've been getting some great feedback from engineers. One issue that some have run into, is that when you download files from the Internet, they can marked as potentially unsafe. One work around is to change the file properties. This helps in allowing you to run the module with execution policy of 'RemoteSigned'. There still could be other reasons within your environment that restrict script usage, but here is a post to help you change the file property of a downloaded Internet resource: https://www.howtogeek.com/70012/what-causes-the-file-downloaded-from-the-internet-warning-and-how-can-i-easily-remove-it/

Update (9/23/2016)

Updated with version 1.1 on the this page and the script center. Minor changes: added additional help content and cmdletbindering to functions. 

Update (5/4/2017)

Uploaded this module to the https://www.powershellgallery.com/ repository which allows users to simply use the following command to import the module to their computers within an Administrator run PowerShell session: Install-Module O365_logon O365_Logon

Comments

  • Anonymous
    December 06, 2015
    Might want to add Azure RMS
    http://eightwone.com/2015/08/31/connecting-to-office-365exchange/
  • Anonymous
    December 07, 2015
    Thank you for the information Michel, I'll look into it.
  • Anonymous
    December 10, 2015
    Hello Mike. I had an issue with Connect-EXO function. Everytime I run it, my PowerShell (same for ISE) crashed. I changed ConnectionUri tohttps://outlook.office365.com/powershell-liveid/ and it started to work.
    Just wanted you to know. Thanks for this module - I think it'll be very useful in my work :)
  • Anonymous
    January 01, 2016
    Robert, thank you for the feedback. I'll look into updating the URI as I know it changes from time to time.
  • Anonymous
    May 02, 2016
    I was putting something like this together myself, and realized someone out there must have already done this better than I could have. Glad to find that I was right. Thanks for the great script. I was wondering, with all of the pre-reqs for running this script, why not add a "Requires" statement at the top to cover them? You could require PS version 3 and each of the required modules, so the script would error out right at the start and explain what requirement(s) is missing. Then again, I can see where requiring each of the Exchange, Sharepoint, and Skype for Business modules might be less than optimal since it would import all required modules each time your module is loaded, but you could still require PS version 3 and the Azure AD module.
    • Anonymous
      May 04, 2017
      Agreed about the #Requires statement, but I don't like it as I try and look for the lowest common denominator to take into account PS v1.0. But yes, I kind of 'assume' some aspects with the module approach. The install .ps1 file helps solve the issues to get to the verb-noun cmdlet functionality. I too was struck with disbelieve no one else had done this first. At least it's out there now.