by Steve Galloway | Dec 22, 2014
Whereas Powershell’s implicit security complicates connectivity to remote servers, authentication provides network administrators with utilities that extend far beyond GUI driven interfaces like Exchange Administration Console (EAC). This article explains how to initiate and terminate remote sessions to third party tenants.
When Powershell is properly configured, network administrators need three commands to open a session, and one command to close a session. Once connected, administrators assign a variable to call tenant ID which in turn enables connectivity to client servers.
Opening a Powershell Session
Import-Module MSOnline
Connect-MsolService
$tenID=(get-msolpartnercontract -domain domainname.com).tenantId.guid
To terminate a session:
Remove-PSSession $Session
Connection script
An unsigned script which automates the commands above and additionally calls the snap-in module for Exchange is available at ComStat’s Script page. If loaded to local drive c:\script, the Powershell command looks like:
c:\script\EXO-Connect.ps1
To test the snap-ins are loaded on sign in, run this command:
get-mailbox
Remember to sign out of sessions using
Remove-PSSession $Session.
Explanation & Concepts
Administrators can handle common management function with Office 365 and Exchange control panels. Occasionally, delegated network administrators need to configure client side processes that Office 365 and EAC does not provide for. Also, Powershell can run one command across several servers simultaneously.
For guidance on Microsoft’s current provisions for advanced management of client tenancies, check here.
Windows PowerShell cmdlets for Office 365
Before using Powershell with Office 365 for the first time, Powershell needs some utilities. Users need to install “MS Online Service Sign-in Assistant for IT Professionals”. Also, the commands that Powershell relies on for Office 365 management are housed in “Azure Active Directory Module for Windows Powershell”. Follow the guidance here to install these services. Another useful download is “Windows PowerShell Module for Lync Online” here.
Cmdlt modules do not install directly into Powershell. Instead, these “snap-ins” sit in a separate directory and called when they are needed for sessions. Modules are managed this way to enable users to rapidly update Powershell’s main cmdlt library, which is updated frequently and is available for download by running this update command:
update-help -force
Using Powershell as a tenant’s global administrator
Delegated administrators can login to client tenants with a tenant’s global administrator credentials if they are available. From a security standpoint, this is not good practice. However, to test Powershell is adequately equipped and session execution policy permissions (more about this below) are properly set, it is worth running a simple script to test the Powershell. For instance, the following script can be used to view basic tenant information on either caistar.com or comstation.co.uk. The script, together with other scripts listed in this article, are available at ComStat’s Sharepoint script site.
c:\script\MSOLTenantDetails.ps1
– more information about this script is available here. At time of writing, this script is unsigned. Depending on your Powershell environment, you may need to run this command:
Set-ExecutionPolicy Unrestricted
Powershell imposes a strict security policy. The policy requires scripts to be “trusted”, and by default Powershell will not execute unsigned scripts. Signing scripts can be done within Powershell. This prevents scripts being tampered with, for example with additional commands that may be malicious. Since the scripts used here are short and can be quickly previewed, another approach when opening Powershell is to run the following command:
Set-ExecutionPolicy Unrestricted
For access to a client’s tenant, follow the guidance below.
Establishing a remote Session
Open Powershell and run the following commands:
Import-Module MSOnline
Connect-MsolService
When prompted, enter the credentials that you use to log into Office 365 portal (MOP) and that allow you to manage Office 365 on behalf of your customers.
Once logged in to Caistar or Comstation, the session will provide for connectivity to other servers to which delegated administration is granted. Commands are run as if executing on the administrator’s server, however each command is programmed to call a variable which points to the target server.
$tenID=(get-msolpartnercontract -domain domainname.com).tenantId.guid
In this case, we establish a variable called “tenantID”. The variable is assigned using the command $tenID= and then a sub routine is executed to call the client’s tenant ID by reference to the domain name associated with the account. Office 365 tenant IDs are longer than credit card numbers, so by calling the tenant ID from client’s domain name and then calling the output “tenantID”, this saves a lot of keystrokes. Here is an example, using hafodrenewables.co.uk (tenant ID = acc617f5-9d4a-4ea9-8823-2385e7d5271a)
$tenID=(get-msolpartnercontract -domain hafodrenewables.co.uk).tenantId.guid
Succesful command execution returns the user to the command prompt. From now, on, commands executed with -tenantID $tenID will execute functions on client servers. To test connectivity, try running this command after assigning a client to a variable to find users on a client server:
get-msoluser -tenantID $tenID
The important point to understand is that Powershell executes commands on a tenant ID, not a domain name. Also, the variable that references the client’s tenant ID must be called with each command, or commands will be executed on the host server. Lastly, by assigning multiple tenant IDs to one variable, administrators can simultaneously run one command across multiple servers and compile output in either formatted tables or even .html. In this way, tasks that might take hours or days can be run in seconds.
Exchange Commands
List Office 365 users:
get-msoluser -tenantID $tenID
Change a user password which never expires:
Set-MsolUser -UserPrincipalName alias@domainname.com -PasswordNeverExpires $true -tenantID $tenID
Test password change:
Get-MSolUser -UserPrincipalName alias@domainname.com -tenantID $tenID |
by Steve Galloway | Dec 16, 2014
This article explains how to connect Outlook 2007 to Exchange Online email services on Office 365. Business Premium and Enterprise users should download Office 2013 App suite from the Office 365 portal. . Outlook 2007 can be connected to Exchange Online, however its architecture was not designed with any anticipation of Microsoft’s Cloud computing services in mind. Outlook 2010 was the first release of Outlook that included considerations for Office 365.
In this respect, Outlook 2007 is not an ideal solution for business users. Outlook 2007 users who do not want to purchase Outlook 2013 for desktop, or do not have access to Outlook 2013 App via their Office 365 subscriptions, should consider using Outlook Web Access (OWA). OWA is a fully specified browser-based alternative to desktop Outlook solutions, and we have experience of companies using OWA as their principle email client to save licensing costs.
Connect Outlook 2007 to Exchange Online
NOTE: Outlook 2007 supports only one Exchange connection per Outlook profile. If Outloo returns an error when you try to add a second Exchange connection to an Outlook 2007 profile, you may need to create a new profile before you can use an Exchange connection with Outlook 2007. For information, see “What else do I need to know?” later in this article.
- Open Outlook 2007. If the Outlook 2007 Startup wizard displays automatically, on the first page of the wizard, click Next. Then, on the E-mail Accounts page of the wizard, click Next again to set up an email account. If the Outlook 2007 Startup wizard does not appear, navigate to the Tools menu and click Account Settings. In the Account Settings dialog box, on the E-mail tab, click New.
- On the Auto Account Setup page, Outlook may try to automatically fill in the Your Name and E-mail Address settings based on how you are logged on to your computer. If the settings are filled in and they are correct, click Next so that Outlook can establish your settings. If the settings in the Auto Account Setup page are not filled in or are inaccurate or wrong, do the following:
- If the settings on the Auto Account Setup page aren’t filled in for you, type the correct settings based on the information that was provided to you by the person who manages your email account.
- If the name in the Your Name box is not correct, you may need to reset the options on the Auto Account Setup page before you can edit your name. To reset the options, select and then clear the check box next to Manually configure server settings or additional server types.
After you click Next on the Auto Account Setup page of the wizard, Outlook will perform an online search to find your email server settings.Outlook 2007 will display a message that asks you to allow a website to automatically set up your account. Outlook must connect to that website periodically to make sure your account is up to date. If you don’t want to see this message every time Autodiscover runs, select Don’t ask me about this website again, and then click Allow.
Outlook 2007 will continue setting up your account. You will be asked for your user name and password before Outlook 2007 can connect to your account. Make sure you enter your full email address (for example, tony@contoso.com) as your user name. You may be prompted to enter your user name and password several times before you connect.
- If Outlook is able to set up your account, you will see the following text: Your email account is successfully configured to use Microsoft Exchange. Click Finish.
- If Outlook is not able to set up your account, see “What else do I need to know?” later in this topic.
What else do I need to know?
- If your email account is the type that requires registration, you need to register it the first time you sign in to Outlook Web App. You won’t be able to connect to your email account using Outlook if you haven’t registered your account through Outlook Web App. After you sign in to your account, sign out. Then try to connect using Outlook. For more information about how to sign in to your account using Outlook Web App, see Sign in to Outlook Web App.
- If Auto Account Setup can’t successfully connect you to your account, do one or more of the following:
- Wait a few minutes and try again.
- If you need to connect to your email account immediately, use a Web browser or an email program that supports POP or IMAP to connect to your account using Outlook Web App. For information about how to connect using a Web browser, see Sign in to Outlook Web App. For information about how to connect using a POP or IMAP email program, see Use IMAP or POP email programs.
- If you know the name of the person who manages your mailbox (sometimes called an email administrator), contact them and report the error you’re getting when you try to connect with Outlook.
- Outlook 2007 supports only one Exchange email account per Outlook profile. If you try to add a second Exchange connection while Outlook is running, you may get the following error. You cannot add a Microsoft Exchange account to this profile while Outlook is running. Exit Outlook and use the Mail icon in the Control Panel to add a Microsoft Exchange account.
- If you already have an Exchange connection in your Outlook profile, you may need to delete the current profile or create a new profile before you can follow the steps in this topic. For more information about Outlook profiles, see Add or remove an email account at the Microsoft Office Online Web site.
by Steve Galloway | Dec 14, 2014
This article explains how to configure Exchange Online for Office 365 Message Encryption. Office 365 Message Encryption is an encryption system delivered via Microsoft’s Information Rights Management (IRM) framework using “transport rules”. When emails meeting criteria, for instance subject headers, are met, the encryption service is run on outgoing email. This means users do not have to deploy services on individual hosts to use encryption services. As long as one or more metrics meet established criteria, email sent from any device will be encrypted when it is processed by the server.
Please read the whole article before beginning work. Configured hosts can be used to manage customers’ servers provided the network administrator has a customer’s global administrator rights.
Powershell users may like to approach this manually, however using the automated approach set out here, users avoid the problem of having to configure a “Trusted Publishing Domain“. Without a Trusted Publishing Domain, IRM services cannot be enabled manually.
Office 365 Message Encryption relies on IRM services which in turn depend on Azure Directory Services (ADS) which is available with E* subscriptions, and possibly with Business Premium. ADS must still be manually activated by going to: Admin – Office 365 – Service Settings – Rights Management.
Once Azure Directory Services are active, IRM can be enabled on Exchange Online Server in a one-off modification, and then users can establish “rules” for Microsoft Office 365 Message Encryption in Admin – Exchange – Mail Flow – Rules.
Workstation Prerequisites:
Office 365 Message Encryption requires IRM services to be enabled on Exchange Online. Although ADS is enabled using the portal, IRM is enabledd via a Powershell remote session to invoke a script provided by Microsoft called EnableIRMforEXO. The remote session requires the four applications to be installed on the local host:
Install the applications in the order listed. Note also that Powershell (PS) mus run in Administrator mode.
PS runs in a restricted mode by default that prohibits the execution of unsigned scripts. If PS has not been modified, users will typically get a PS error message like:
File C:\Common\Scripts\hello.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see “get-help about_signing” for more details.
At line:1 char:13
+ .\hello.ps1 <<<<
+ CategoryInfo : NotSpecified: (:) [], PSSecurityException
+ FullyQualifiedErrorId : RuntimeException
To enable scripting, open PS and run the following command. This is a one time command, and can be disabled.
set-executionpolicy remotesigned
Enabling IRM on Exchange Online
Using the unzipped script – EnableIRMforEXO – Powershell establishes a remote session with Exchange Online Server, and on confirmation of location and user credentials, executes the necessary server modifications. The command can be fully executed with strings for “location” and “get-credentials”, however the cmdlet works more reliably if it is left to call for location and credentials itself. These instructions assume the script is installed in c:\scripts\
- open Powershell
- enter c:\scripts\EnableIRMforEXO
- when prompted for location, input European Union
- complete when prompted for user name etc.
The process will execute and return results. This should be adequate for enabling Office 365 Message Encryption.