Role Based Access Control (RBAC) enables us to control the level of administrative control granted to IT staff and users in an Exchange organization. Exchange Server 2010 and later versions ship with a number of built-in role groups that we can make use of without having to create our own custom RBAC roles.

For example, Organization Management is a powerful group that grants almost complete administrative control over an Exchange organization, whereas Help Desk is a more limited role that only allows some recipient management tasks to be performed.

Hopefully you’re already making good use of the built-in RBAC roles, or creating your own custom roles, instead of simply granting all of your IT staff Organization Management privileges. Even so, from time to time it is a good idea to review your RBAC role group membership to verify that IT staff have the minimum required access.

I’ve written a simple PowerShell script that will enumerate the membership of the role groups in an Exchange organization and produce a report listing the user accounts that are members of each group, as well as other interesting information such as whether the users are enabled or disabled, and how long ago they changed their password. It can be alarming to discover that an Organization Management role group member hasn’t changed their password in several years.

You can download Get-RBACGroupMemberReport.ps1 from TechNet or Github.

Run the script from a server or workstation that has the Exchange management tools installed. The script also relies on some cmdlets from the Active Directory PowerShell module, so that also needs to be installed on the system.

There are no parameters or switches required, simply run the script from PowerShell.

PS C:\Scripts\RBAC> .\Get-RBACGroupMemberReport.ps1

Some progress information is output to the console as it runs.

A CSV file is produced for each group that contains one or more members, as well as a Summary.csv file.

The Summary.csv file will show you the count of members per group, including enabled/disabled user counts.

The CSV file for each role group will also show you which users are enabled/disabled, and the age of their passwords.

Use this script to regularly review your RBAC role group membership and keep your Exchange organization secure.

Feedback and questions are welcome in the comments below.

This article PowerShell Script to Report RBAC Role Group Membership is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Antivirus software that is not correctly configured is a fairly common cause of many performance and stability issues with Exchange. It’s a good idea to run antivirus software on your Exchange 2013 servers to help prevent malware, and I always recommend it to customers. But if you do install antivirus software you need to configure it with the correct exclusions so that it doesn’t interfere with Exchange Server’s operations.

Microsoft has published a list of file/folder, process, and file type exclusions that should be applied to antivirus software running on an Exchange 2013 server. It’s quite long, and you might notice some duplication of effort. For example, Microsoft recommends excluding the path of the database files (eg, F:\DB01\DB01.edb) but also the file type .edb. Why both? Well it’s just a precaution in case a database is moved to a different path without updating the exclusions list, or if the antivirus software you’re using needs to handle the exclusions a specific way.

Since the exclusions list is so long and relies on a number of variables (eg the Exchange install path is something you can choose during setup, so it won’t always be C:\Program Files\…), working out the actual list of exclusions is a very long and tedious task.

That’s why I’ve written a PowerShell script to generate the list quickly and easily.

Get-Exchange2013AVExclusions.ps1 can be downloaded from TechNet Script Gallery or Github.

The script is run directly on an Exchange 2013 server using the Exchange Management Shell. If you’re deploying multiple servers with the same configuration (eg members of a database availability group) you can use the script to generate the exclusions list off one server and then use your antivirus software’s policy-based management to deploy the same settings to all of your servers.

Simply run the script with no parameters to generate the exclusions lists.

[PS] C:\Scripts\av>.\Get-Exchange2013AVExclusions.ps1
Done.

The result is three text files; one for the file/folder paths, one for the processes, and one for the file extensions.

Feedback and questions are welcome in the comments below.

This article PowerShell Script to Generate Antivirus Exclusions List for Exchange Server 2013 is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Microsoft has announced the public release of Exchange Server 2016 Preview, available for download now.

This version of Exchange is special because it was born in the cloud. From the depths of the mailbox store to the most visible parts of the Outlook web UI, the bits that make up Exchange 2016 are already in use across millions of mailboxes in Office 365. For the past several months we’ve been working to package up these capabilities and deliver them on-premises. This preview milestone is an important step in that process, and we’re excited to include the worldwide Exchange community in the journey.

For Exchange admins a new release like this can be an exciting time. Looking at the information in Microsoft’s announcement and the documentation already available on TechNet (which is incomplete of course, but we can expect it to fill up rapidly in the coming months) there is certainly plenty to get excited about.

For Exchange Server 2013 customers there are no unpleasant surprises and we can mostly enjoy the improvements in performance, manageability, and user experience.

For Exchange Server 2010 customers there are more obvious changes, mostly in areas that Exchange 2013 customers are already used to such as the changes in management tools and the server roles architecture.

Architectural Changes in Exchange Server 2016

The big change in the server roles architecture is the further consolidation of server roles into just two:

• Mailbox server role
• Edge Transport server role

The Mailbox server role consolidates both of the required Exchange Server 2013 roles (Mailbox and Client Access), and all of the required Exchange Server 2010 roles (Mailbox, Client Access, Hub Transport, and Unified Messaging) into a single server role.

Within that single server role there still exists the concept of “Mailbox services” and “Client Access services”, but the immediate benefit is no more confusion over whether to deploy separate roles or multi-role servers.

This purpose of the Edge Transport role remains unchanged, designed to sit in perimeter networks and provide secure inbound and outbound mail flow. As with previous versions of Exchange this is an optional server role.

Co-Existence Improvements in Exchange Server 2016

Welcome news for Exchange Server 2013 customers is the capability for Exchange Server 2013 and 2016 to proxy client traffic to each other, instead of having to cut over all client access namespaces to the higher version during a co-existence period. This will ease the migration path for many customers, and no doubt makes the transition within Office 365 easier for Microsoft to manage as well.

Outlook on the Web (formerly Outlook Web App)

Outlook’s web-based experience is going through yet another name change, now generally referred to as “Outlook on the web” to align with the unification of the Outlook brand across all platforms.

I use Outlook Web App daily and the richness of the experience means I don’t miss the full Outlook application at all when it is not available to me. More improvements in Outlook for the web are always welcome by me, and I’m particularly interested in the new “Pins and Flags” features, as I like to “pin” items to the top of my mailbox as a sort of “to do” list (Outlook.com already behaves this way when you flag an item).

Faster Search Performance

As mailboxes get bigger and more mail items are kept for longer periods of time search becomes more and more important for end users. For years now I’ve personally used a “just file it into one folder and use search to find it later” approach to keeping my Inbox from accumulating too many items, and I meet more people taking this approach as time goes on.

Microsoft says:

By studying real-world data about how people search and analyzing the speed at which results are returned, we’ve implemented changes to the search architecture and user interface of Office 365, which are now coming on-premises.

The overall speed of server side search is significantly improved in Exchange 2016. But more importantly, the Outlook client now fully benefits from the power of server-side search. When a cached mode Outlook 2016 client is connected to Exchange, it performs search queries using the speed and robust index of the server, delivering faster and more complete results than desktop search.

Some insight into this research was shared by Karim Batthish during the “Meet Exchange Server 2016″ session at Ignite 2015, and I highly recommend watching it as it was very interesting to see how Microsoft approached this challenge.

Modern Authentication for Outlook

Exchange Server 2016 supports modern authentication, which has been discussed for Office 2013 and Office 365 scenarios in this blog post by Microsoft.

One of the scenarios this opens up is the use of multi-factor authentication for Outlook clients connecting to on-premises Exchange Server 2016. Having worked with many customers who block Outlook Anywhere for the lack of MFA support this is a welcome addition.

New Hybrid Configuration Wizard

The Hybrid Configuration Wizard for configuring a Hybrid Exchange and Office 365 deployment has been removed from Exchange Server 2016 and is now a standalone tool.

In the past there has been times when changes in the cloud broke the HCW for Exchange Server 2013, which then couldn’t be fixed until the next cumulative update was released. Now as a separate tool Microsoft can maintain the HCW with any changes or fixes required to continue working with Office 365.

Other Changes

The list of significant changes is much longer than just those items above, and you can expect that I and others in the Exchange community will be sharing a lot of information over the coming months as we get closer to Exchange Server 2016 RTM.

Other changes of interest include:

• MAPI over HTTP is being prioritized as the Outlook connectivity protocol, with RPC over HTTP de-emphasised and likely to be phased out in future versions of Exchange.
• Exchange Server 2016 database availability groups will be created without an IP address (administrative access point) by default, but can be created with an IP if necessary. Backup software vendors need to get on board with this change if they have not already.
• Auto-expanding archive mailboxes, recently enabled in Office 365, will be available in Exchange Server 2016 (but only accessible past the initial 100Gb limit by Outlook 2016 and Outlook on the web).
• Many improvements and updates to compliance features like DLP, transport rules, in-place hold, and eDiscovery.

This article Exchange Server 2016 Preview Has Been Released to the Public is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Microsoft has released a new application for Office 365 customers that is designed to be used for short, instant-message style communications via email. The app is named Send and is available in the US and Canadian iTunes App Store, with plans to release it globally in the near future.

While tools like text messaging and IM are great for short messages, you often don’t have your co-worker’s cell phone number or an IM app on your work phone. And we’ve heard loud and clear from people at work, they want all their communications available in Outlook—even if they send them from other apps. This is where Send comes in! Send gives you the simple, quick text message-like experience while allowing you to reach all co-workers and have all of your communications in Outlook for reference later.

I immediately like this app, even though here in Australia I can’t download and use it yet. Having previously worked in large, distributed operations teams I remember how frustrating it was having to manage mobile phone numbers for lots of people in my phone contacts, while also having conversations that were split between text messaging and email.

Sure, services like Skype for Business have IM capabilities as well.  But let’s be honest, not every organization that has Office 365 today also has Skype for Business widely deployed and in use for their users (though they should!). And although there are many other chat/IM applications out there today, Send has the advantage of integrating into your actual mailbox as well. For compliance-focused organizations this is a big plus. And for the end users it is very convenient.

I also like that the Microsoft Garage is releasing apps like this and experimenting with ways to improve communications in our lives.

Anyway, when a new email-related application like this is released the first reaction for some people is “how do I block this thing while I evaluate it against our organization’s policies?”

Let’s take a look at how Send connects to Exchange Online. From the Send FAQ posted to Yammer:

Send works with the same infrastructure that Office 365 does – Azure AD for authenticating the user, and Exchange to transport and store messages. In addition, Send has a service on Azure that contains our business logic to make sure only messages originated from Send will show up in Send. The Send Azure service connects to Exchange Online through Exchange Web Services managed APIs.

Connecting through Exchange Web Services means Send is not subject to ActiveSync mobile device policies. What about enforcing security features such as device PINs, you ask? Good question.

Currently there is no functionality built within the app that enables an admin to set PIN lock for the app. If your organization has set Exchange ActiveSync policies, then device-level PIN is likely already enforced by the devices main email client (e.g. iOS Email app, or Outlook app). Also, most MDM solutions will let you set a PIN lock for your user’s work device.

So you’re covered if the user’s mobile device is already complying with an ActiveSync or MDM policy that you’ve applied. But what about devices that don’t have an ActiveSync email profile set up, or aren’t enrolled in your MDM?

Well… those devices can connect with Send regardless of their compliance with your organization’s policies.

But that doesn’t leave you with no options. Being an Exchange Web Services application you can still control whether it is allowed to connect or not. In fact, I recently published an excerpt from our eBook “Office 365 for Exchange Professionals” that explains how to manage Exchange Web Services in Office 365.

To apply EWS controls for the Send app you need the user agent string. This string was unfortunately absent from the FAQ when I read it earlier today, but the folks at Microsoft helpfully let me know that the string “MicrosoftSend/*” can be used.

First, connect to Exchange Online with PowerShell.

To block Send for the entire organization, first enable EWS block list enforcement (if it is not already enabled), then add the user agent string to the block list.

PS C:\> Set-OrganizationConfig -EwsApplicationAccessPolicy EnforceBlockList
PS C:\> Set-OrganizationConfig -EwsBlockList @{add="MicrosoftSend/*"}

That will take effect for the entire org, including any admins or security people who need to evaluate the application.

If you’d prefer to block it for individual mailboxes you can use the same method shown above, but use Set-CASMailbox instead of Set-OrganizationConfig.

PS C:\> Set-CasMailbox Alan.Reid -EwsApplicationAccessPolicy EnforceBlockList
PS C:\> Set-CasMailbox Alan.Reid -EwsBlockList @{add="MicrosoftSend/*"}

You can also disable EWS entirely for a mailbox (without impacting other applications like Outlook), as demonstrated in this article.

If you do choose to block Send for your Office 365 organization I hope you will also plan to properly assess the application with a view to allowing it in future if it is found to comply your organization’s policies. Standing between users and useful communication tools like Send is not a good way for IT departments to add value to a company.

If you plan to block or allow Send please let us know your reasons in the comments below. And if you’re already using it I’d love to hear more about the user experience while I wait for the app to be released here in Australia.

This article Controlling Microsoft Send App Access with Exchange Web Services is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

When an external sender attempts to send an email message to an Office 365 group they may receive a non-delivery report (NDR).

The NDR states:

Your message couldn’t be delivered because the group you’re sending to needs to know who you are before it will accept your message. To fix this problem, as the email admin for the group to configure the group to accept messages from you.

There is additional information for email administrators:

This error occurs when the group is configured to reject email from senders outside of the group’s organization.

There is additional diagnostic info with a specific NDR status code:

Remote Server returned ‘550 5.7.133 RESOLVER.RST.SenderNotAuthenticatedForGroup; authentication required; Delivery restriction check failed because the sender was not authenticated when sending to this group’

This type of NDR is usually caused by the setting on groups in Office 365 that controls whether people outside the organization can send email to the group. When a group is first created in Exchange Online, whether it is created manually or by a cutover/staged migration, the setting defaults to “Off”. This setting is visible in the Office 365 admin portal, in the Groups section.

Switch the setting to “On” to enable external senders to send email to the group.

You can also perform this change in PowerShell. After connecting to Exchange Online with PowerShell use the Set-DistributionGroup cmdlet to modify the setting.

PS C:\> Set-DistributionGroup teamalpha -RequireSenderAuthenticationEnabled $false

This article Office 365: Delivery Has Failed to These Recipients or Groups is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

While exploring the Office 365 Import Service in my test lab I encountered repeated timeout errors trying to upload PST files to Azure using AzCopy.exe.

[2015/07/26 23:26:36.206+10:00] >>>>>>>>>>>>>>>>
[2015/07/26 23:26:36.221+10:00][VERBOSE] 3.1.0 : AzCopy /source:\\mgmt\pst /dest:https://uploadurl.blob.core.windows.net/ingestiondata/ /DestKey:****** /S /V:C:\Admin\PSTupload.log
[2015/07/26 23:26:39.680+10:00][VERBOSE] Start transfer: Alan Reid.pst
[2015/07/26 23:26:40.352+10:00][VERBOSE] Start transfer: Dawn Evans.pst
[2015/07/26 23:26:40.352+10:00][VERBOSE] Start transfer: Elaine West.pst
[2015/07/26 23:26:40.352+10:00][VERBOSE] Start transfer: Vik Kirby.pst
[2015/07/26 23:41:41.552+10:00][VERBOSE] Transfer FAILED: Alan Reid.pst.
[2015/07/26 23:41:41.568+10:00][ERROR] Alan Reid.pst: The client could not finish the operation within specified timeout.
The client could not finish the operation within specified timeout.
[2015/07/26 23:52:41.450+10:00][VERBOSE] Transfer FAILED: Elaine West.pst.
[2015/07/26 23:52:41.450+10:00][ERROR] Elaine West.pst: The client could not finish the operation within specified timeout.
[2015/07/26 23:52:41.450+10:00][VERBOSE] Transfer FAILED: Vik Kirby.pst.
[2015/07/26 23:52:41.450+10:00][ERROR] Vik Kirby.pst: The client could not finish the operation within specified timeout.
[2015/07/26 23:53:23.429+10:00][VERBOSE] Transfer FAILED: Dawn Evans.pst.
[2015/07/26 23:53:23.429+10:00][ERROR] Dawn Evans.pst: The client could not finish the operation within specified timeout.
The client could not finish the operation within specified timeout.
[2015/07/26 23:53:23.445+10:00] Transfer summary:
-----------------
Total files transferred: 4
Transfer successfully:   0
Transfer skipped:        0
Transfer failed:         4
Elapsed time:            00.00:26:47

I was trying to upload using my home internet connection, which doesn’t have high upload speed. The upload process was also showing a transfer speed of 0 KB/s. Clearly it was not making any progress.

Reviewing the AzCopy command line options I saw that there is a /NC parameter that can be used to control the number of concurrent operations.

AzCopy by default starts a certain number of concurrent operations to increase the data transfer throughput. Note that large number of concurrent operations in a low-bandwidth environment may overwhelm the network connection and prevent the operations from fully completing. Throttle concurrent operations based on actual available network bandwidth.

Lowering the thread count to 2 (by specifying /NC:2) seems to have resolved the issue for me, and the upload was able to finish on the next attempt.

This article PST Upload using AzCopy.exe Could Not Finish the Operation Within Specified Timeout is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Exchange Server 2016 can be installed on Windows Server 2012 and Windows Server 2012 R2. For both versions of Windows Server either the Standard or Datacenter edition can be used to run Exchange Server 2016. Exchange itself does not rely on any specific features of either the Standard or Datacenter editions.

Note that a full server installation with GUI is required for Exchange Server 2016, it can’t be installed on a Core mode installation of Windows Server.

There are three possible installations of Exchange Server 2016 that you can perform:

• Mailbox server role (this is the only mandatory server role)
• Edge Transport server role (this is optional, and can’t co-exist with the Mailbox server role on the same Windows Server)
• Management Tools (for admin workstations or servers)

The requirements for each installation type are different, so let’s look at each of them in turn.

Installing Pre-Requisites for an Exchange Server 2016 Mailbox Server

For an Exchange Server 2016 Mailbox server installation open an elevated (run as administrator) PowerShell console and run the following command to install the operating system roles and features.

C:\> Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

A restart is required after the roles and features have finished installing. If you’d prefer that the server restarts itself automatically simply append -Restart to the command.

After the restart download and install (in order):

• .NET Framework 4.5.2
• Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit

The server is now ready to install Exchange Server 2016.

Installing Pre-Requisites for an Exchange Server 2016 Edge Transport Server

For an Exchange Server 2016 Edge Transport server the pre-requisites installation is a little simpler than for a Mailbox server. Open an elevated PowerShell console and run the following command.

C:\> Install-WindowsFeature ADLDS

When that has completed download and install (in order):

• .NET Framework 4.5.2
• Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit

The server is now ready to install the Exchange Server 2016 Edge Transport role.

Installing Pre-Requisites for the Exchange Server 2016 Management Tools

Exchange Server 2016 uses a web-based administrative interface called the Exchange Admin Center, similar to Exchange Server 2013. There is nothing required to be installed on a workstation or server other than a web browser to access the Exchange Admin Center.

However if you want the Exchange Management Shell to be installed on a management workstation or server (Windows Server 2012 R2 or Windows 8.1) then the only pre-requisite is to install .NET Framework 4.5.2. After the .NET Framework is installed you can install the Exchange Server 2016 management tools.

Next Steps

After installing the pre-requisites you can proceed with installing Exchange Server 2016.

This article Installing Exchange Server 2016 Pre-Requisites on Windows Server 2012 R2 is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

After you’ve prepared a Windows Server with the Exchange Server 2016 pre-requisites you can proceed with the installation of Exchange Server itself.

In this tutorial we’ll cover:

• Preparing Active Directory for Exchange Server 2016 installation
• Installing the Exchange Server 2016 Mailbox server role on a new server

Before you start there are a few things to be aware of:

• Installing Exchange Server 2016 requires an Active Directory schema update. We’ll look at that in more detail shortly.
• Aside from the schema update installing Exchange Server 2016 makes other irreversible changes to your Active Directory forest. If you’ve never backed up your Active Directory, or you’ve never heard of a forest recovery, here’s some reading for you.
• If you’re installing Exchange into the forest for the first time you will be choosing an organization name. The Exchange organization can’t be renamed at a later date, so choose a name you’re happy with keeping forever.

Preparing Active Directory

A new installation of Exchange Server 2016 involves applying an Active Directory schema update, as do most Exchange Server cumulative updates, as well as preparing the Active Directory domains where Exchange Server 2016 and any mail-enabled objects will be located. In an Active Directory forest with a single domain this can all be performed as one task.

The Active Directory schema update will automatically apply when you run Exchange Server 2016 setup on the first server in your environment. A Windows Server 2012 R2 server with the Exchange Server 2016 Mailbox server role pre-requisites installed doesn’t quite meet the requirements (you’ll need to add the RSAT-ADDS feature as shown below). A domain controller will have RSAT-ADDS installed already, but may also need the .NET Framework version shown below to be installed first.

Whether you’re running the schema update from an Exchange server or a separate server (some organizations do it as a separate task due to change control reasons, or because of different teams having different administrative responsibilities in the environment) then the following requirements apply:

• .NET Framework 4.5.2 must be installed
• The RSAT-ADDS feature must be installed

C:\> Install-WindowsFeature RSAT-ADDS

• The forest functional level must be at least Windows Server 2008
• The account used to run the schema update and Active Directory preparation must be a member of Enterprise Admins and Schema Admins. These are high privilege groups I recommend you plan to remove your account from the groups when you’re done with this task. Note, if you’ve just added yourself to these groups you’ll need to log out and back in to the server for the new group membership to take effect.
• The server you’re running the schema update from must be located in the same Active Directory site as the Schema Master. You can identify your Schema Master by running my Get-ADInfo.ps1 script, or by using the Get-ADForest PowerShell cmdlet.

PS C:\> (Get-ADForest).SchemaMaster

Now we’re ready to run the Active Directory schema update and and preparation.

If you’ve already got Exchange Server running in your environment you can check the current Exchange schema version before applying the update, so that you can see what the before and after version numbers are.

In PowerShell run the following one-liner created by Exchange Server MVP Michael B Smith:

PS C:\> "Exchange Schema Version = " + ([ADSI]("LDAP://CN=ms-Exch-Schema-Version-Pt," + ([ADSI]"LDAP://RootDSE").schemaNamingContext)).rangeUpper
Exchange Schema Version =

Note, in my example above there is no existing Exchange server installed, hence no Exchange schema version to report.

Extract the Exchange Server 2016 setup files into a folder, open a command prompt window, and then navigate to the location where the Exchange setup files were extracted.

To apply only the schema update run the following command:

C:\Admin\ex2016>setup /PrepareSchema /IAcceptExchangeServerLicenseTerms
Welcome to Microsoft Exchange Server 2016 Unattended Setup
Copying Files...
File copy complete.
Setup will now collect additional information needed for
installation.
Performing Microsoft Exchange Server Prerequisite Check
    Prerequisite Analysis                                     COMPLETED
Configuring Microsoft Exchange Server
    Extending Active Directory schema                         COMPLETED
The Exchange Server setup operation completed successfully.

After applying the schema update we can check the version number again.

PS C:\> "Exchange Schema Version = " + ([ADSI]("LDAP://CN=ms-Exch-Schema-Version-Pt," + ([ADSI]"LDAP://RootDSE").schemaNamingContext)).rangeUpper
Exchange Schema Version = 15317

To prepare Active Directory run one of the following commands. Note this will also apply the schema update if you did not perform that step already.

If you do not already have an Exchange organization you’ll need to provide a name for the organization now, for example:

C:\Admin\ex2016>setup /PrepareAD /OrganizationName:"Exchange Lab" /IAcceptExchangeServerLicenseTerms

If you’re installing Exchange Server 2016 into an existing Exchange organization you do not need to specify the organization name, for example:

C:\Admin\ex2016>setup /PrepareAD /IAcceptExchangeServerLicenseTerms

Remember, you can’t change the Exchange organization name later, so choose a name you’ll be happy to live with forever. Also, after installing Exchange Server 2016 as a new organization you will not be able to install any earlier versions of Exchange into the same organization.

C:\Admin\ex2016>setup /PrepareAD /OrganizationName:"Exchange Lab" /IAcceptExchan
geServerLicenseTerms
Welcome to Microsoft Exchange Server 2016 Unattended Setup
Copying Files...
File copy complete.
Setup will now collect additional information needed for
installation.
Performing Microsoft Exchange Server Prerequisite Check
    Prerequisite Analysis                                     COMPLETED
 Setup will prepare the organization for Exchange Server 2016 by using 'Setup /P
repareAD'. No Exchange Server 2007 roles have been detected in this topology. Af
ter this operation, you will not be able to install any Exchange Server 2007 rol
es.
 For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms
.exch.setupreadiness.NoE12ServerWarning.aspx
 Setup will prepare the organization for Exchange Server 2016 by using 'Setup /P
repareAD'. No Exchange Server 2010 roles have been detected in this topology. Af
ter this operation, you will not be able to install any Exchange Server 2010 rol
es.
 For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms
.exch.setupreadiness.NoE14ServerWarning.aspx
Configuring Microsoft Exchange Server
    Organization Preparation                                  COMPLETED
The Exchange Server setup operation completed successfully.

If you have additional domains in your forest that you need to prepare (any domain that will host an Exchange server or mail-enabled objects) follow the guidance on TechNet here.

Installing the Exchange Server 2016 Mailbox Server Role

The Mailbox server role contains all of the components required to run an Exchange Server 2016 server. There is also an Edge Transport role, but that is not a mandatory role and is not covered in this tutorial.

After installing the Exchange Server 2016 pre-requisites on a server you can install the Exchange Server 2016 Mailbox server role by running the following command from an elevated command prompt.

C:\Admin\ex2016>setup /Mode:Install /Role:Mailbox /IAcceptExchangeServerLicenseTerms
Welcome to Microsoft Exchange Server 2016 Unattended Setup
Copying Files...
File copy complete.
Setup will now collect additional information needed for
installation.
Languages
Management tools
Mailbox role: Transport service
Mailbox role: Client Access service
Mailbox role: Unified Messaging service
Mailbox role: Mailbox service
Mailbox role: Front End Transport service
Mailbox role: Client Access Front End service
Performing Microsoft Exchange Server Prerequisite Check
    Configuring Prerequisites                                 COMPLETED
    Prerequisite Analysis                                     COMPLETED
Configuring Microsoft Exchange Server
    Preparing Setup                                           COMPLETED
    Stopping Services                                         COMPLETED
    Copying Exchange Files                                    COMPLETED
    Language Files                                            COMPLETED
    Restoring Services                                        COMPLETED
    Language Configuration                                    COMPLETED
    Exchange Management Tools                                 COMPLETED
    Mailbox role: Transport service                           COMPLETED
    Mailbox role: Client Access service                       COMPLETED
    Mailbox role: Unified Messaging service                   COMPLETED
    Mailbox role: Mailbox service                             COMPLETED
    Mailbox role: Front End Transport service                 COMPLETED
    Mailbox role: Client Access Front End service             COMPLETED
    Finalizing Setup                                          COMPLETED
The Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to
take effect. Please reboot this server prior to placing it into production.

Next Steps

After setup has completed restart the server before you continue with configuring Exchange Server 2016.

This article Installing Exchange Server 2016 is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Customers using Office 365 can use built-in mobile device management capabilities that are included in the service to securely manage their employees mobile devices, including employee-owned mobile devices in a “bring your own device” (BYOD) environment.

The benefits of Office 365 mobile device management (MDM) include:

• Device management – enforce security policies such as PIN/passcode requirements, and prevent jailbroken devices from accessing your corporate data.
• Conditional access – allow access to corporate data only from devices that are managed by your company and that are compliant with your policies.
• Selective wipe – remove corporate data from employee mobile devices while leaving their personal data intact.

Comparisons Between Exchange ActiveSync and Office 365 MDM

Anyone already familiar with managing mobile devices using Exchange ActiveSync may wonder why these Office 365 MDM capabilities are necessary. After all, ActiveSync and mobile device policies are already available in Exchange Online and Exchange Server on-premises. While this is true, the capabilities of ActiveSync vs Office 365 MDM are different, and are designed to solve different problems.

ActiveSync takes a device-centric approach to mobile device management. ActiveSync is used to allow, block or quarantine mobile devices that are accessing Exchange mailbox data such as email, contacts, and calendars. The user-centric controls for ActiveSync extend only as far as enabling or disabling the protocol for a user’s mailbox. Beyond that any allow/block/quarantine is based on device characteristics such as make, model or user agent, even when you are approving or blocking a device for an individual user.

And even though ActiveSync and mobile device policies can be used to enforce security policies such as PIN/passcode requirements, those policies can be circumvented by the connecting device or application as we saw with the initial release of Outlook for iOS and Android.

Furthermore, if a mobile device is not connected to a mailbox using ActiveSync then it is not subject to any policy enforcement at all. With Office 365 this means that the same device could be used to access corporate data using Office Mobile apps and OneDrive for Business without any device security policies being applied. Office 365 MDM closes that security gap by allowing organizations to enforce device management and security policies on any mobile device that is accessing corporate data. Office 365 also takes a user and group-centric approach for targeting policies

The lack of selective wipe in ActiveSync has also been a cause of conflict in the past for many organizations, with employees not taking too kindly to IT administrators remotely wiping their entire mobile device including personal data. The workaround for this has usually been to use a non-native email application such as Touchdown or Outlook for iOS and Android, which sometimes means incurring additional costs to purchase apps, or putting up with limited integration with the device OS and other apps. Again, Office 365 solves these issues by allowing selective wipe.

Device and Application Support for Office 365 MDM

At Ignite 2015 Microsoft presenters used this slide to communicate the device and application support for Office 365 MDM. Basically this means support for iOS and Android versions released in the last couple of years, their native mail applications, and the Office Mobile applications for those platforms. There’s been a few changes since Ignite with the Outlook app on iOS and Android now including compatibility with Office 365 MDM.

Windows Phone 8.1 is unlikely to be updated to support Office 365 MDM and fans of Windows Phone may need to wait for Windows 10 Mobile instead.

Office 365 MDM Policies for Mobile Devices

The policy controls available for administrators to allow or block mobile devices from connecting to Office 365 resources can be summarised as follows:

• Security settings – device PIN/passcode, including length and complexity, as well as inactivity timeout (device lock) and failed login attempts
• Device encryption – enabled by default in Windows Phone 8.1, enforceable for Android, not enforceable for iOS
• Jail broken device detection – this includes “rooted” Android devices
• Managed email profile – iOS only (email profile is set up automatically, and manually created profiles are blocked)

Depending on the mobile device type a variety of other policy controls are also available, such as blocking screen capture (preventing data leakage by screen capture), blocking app stores, blocking removable storage, and other device feature such as cameras and voice dialling. A full list of policy capabilities for each mobile platform is available on TechNet.

Deploying Office 365 Mobile Device Management

If you are planning to deploy Office 365 MDM for your organization the process involves:

1. Audit your existing mobile devices
2. Develop or update your organization’s mobile device policies
3. Activate MDM for Office 365
4. Create MDM policies, perform testing and piloting
5. Communicate with end users and enrol their mobile devices
6. Ongoing management and reporting

We’ll explore this process in more detail in a series of upcoming articles.

This article Introduction to Office 365 Mobile Device Management is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Before you can use the Office 365 Mobile Device Management features you will first need to activate it in your Office 365 tenant.

Log in to the Office 365 admin center with your tenant administrator credentials. Select Mobile Devices in the left pane and then click the Get Started button.

There will be a short delay while MDM is activated for your tenant. The message suggests waiting a few hours, but I’ve generally seen it complete within a few minutes.

When MDM activation has completed you should see a red warning icon to let you know that some more settings need to be configured.

Click the Manage Settings link to see a report of the MDM setup steps that you need to complete. The required steps are:

• Configure domains for MDM
• Configure an APNs  (Apple Push Notifications) certificate for iOS devices

If you have previously turned off DNS checking for the domain name in your Office 365 tenant then you may see a green tick for “Configure domains for MDM” even though you have not configured the domain for MDM. I recommend checking your domain configuration even if you see a green tick for that item.

Configuring Domains for Office 365 Mobile Device Management

To configure your domain navigate to the Domains section of the Office 365 admin portal, select your domain name, and click the Domain settings link.

Click the link to Change domain purpose.

Check the box to enable Mobile Device Management for Office 365, then click Next.

Some additional DNS records, “enterpriseregistration” and “enterpriseenrollment” will be presented for you to add to the public DNS zone for your domain name.

If the new records won’t immediately validate you can still proceed with other MDM setup tasks and check the DNS records again later.

Configure an APNs Certificate for iOS Devices

In the list of required steps for Office 365 MDM setup click the Set up link for configuring an APNs certificate for iOS devices.

Your web browser will be redirected to a page where you can download the certificate signing request (CSR) for provisioning the new APNs certificate. Download the file to a safe location on your computer and click Next.

Next you need to sign in to the Apple APNS Portal to request the certificate. An Apple ID is required for this task. It is strongly recommended that you do not use an Apple ID that is owned by an individual, rather you should create a new one that is associated with an email address in the company. If you don’t already have a company Apple ID take a few minutes now to create one on the Apple website, then return to continue the setup tasks.

After logging in to the Apple APNS Portal click the Create a Certificate button.

After accepting the license agreement click the Browse button and select the CSR that you downloaded from the Office 365 admin portal earlier, then click the Upload button.

The upload returns a JSON formatted file to your web browser. You can save the file if you like, but this is not the certificate file you need.

You will receive a notification to the email address for your Apple ID when the certificate has been created. If your web browser is stuck on the “Uploading…” page simply refresh it to see your available certificates in the portal. Click the Download button to download your new certificate as a PEM file.

Return to the web browser tab or window for Office 365 where you are configuring the APNs certificate, and click Next to continue to the page to upload your new certificate. Click the Browse button and select your PEM file to upload.

The certificate install takes several minutes to complete. If your web browser appears to hang or time out on the upload you can log back in again, start the process of configuring the APNS certificate, and just skip through to the last step to upload the certificate you already have instead of requesting another new one.

If everything is in order you should see a green tick for the Mobile Device Management settings and you can start creating MDM policies for Office 365.

This article Office 365 Mobile Device Management – Activation and Initial Configuration is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

While running the Hybrid Configuration Wizard for an Exchange/Office 365 hybrid deployment one of the steps involves adding TXT records to your DNS zones to prove ownership of the domains being configured for federation.

There’s a particular DNS host in Australia that I keep encountering that has a bug in their control panel. The TXT records often contain “+” characters, which this control panel bug removes. It’s not the sort of thing that is easy to spot when you’re squinting at your laptop screen, so I ended up writing a script to check it for me.

Download Test-FederatedDomainProof.ps1 from Github.

This PowerShell script is very simple to use. It requires the Exchange Management Shell, and you simply tell it which domain name you want to test and the script will query a Google DNS server for the TXT records for that domain and compare it to the string that is generated as the federated domain proof.

When the script runs you’ll simply see a green or red message at the end indicating success or failure.

Because of the way the proof string is generated you should run the script from within the Exchange organization that owns the domain.

This article PowerShell Script to Test Federated Domain Proof TXT Record for Hybrid Deployments is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Managing device policies for Office 365 Mobile Device Management is performed in the Unified Compliance Console. If you’re already logged in to the Office 365 admin portal you can navigate to the Mobile section and click the link to “Manage device security policies and access rules.”

Note, before you begin managing device policies should have already performed the initial setup for Office 365 MDM.

In the Device Management view you’ll see a list of device policies that are already configured. There are no default policies created when you enable Office 365 MDM, so if this is your first look at this page then it’s likely you’ll see an empty list.

There are two types of controls that you can apply:

• Organization-wide default policies
• Device policies targeted at groups of users

Office 365 Mobile Device Management policies are targeted at security groups. Before you begin configuring policies I recommend you create security groups in Office 365 to be used for policies.

Configuring Organization-Wide Policies in Office 365 MDM

Click the link to “Manage organization-wide settings for device access management.” Here you can decide whether to allow or block unsupported devices from accessing email when they are targeted by an MDM device policy. If your organization is going to require mobile device management for all connecting devices then you should plan to configure this to “Block“.

However, there are always exceptions to these types of rules. Perhaps you are currently in the testing or pilot phase of your Office 365 MDM project, and do not want to enforce a setting that my disrupt other users while you complete your testing. Or perhaps you want to allow your users time to enrol in MDM before cutting off their regular ActiveSync access. In that case you may wish to leave the setting as “Allowed” for now.

If you do want to block unsupported devices you might still have some scenarios where a block is not desirable. For example, you might have a VIP user who has received an exemption for their preferred device that happens to be unsupported. In these cases you can specify a group of users who are excluded from access control.

Note that before you can add a group to this exclusion list you need to have created the group in Office 365 already. Also be aware that the group picker will show no groups at first even if you have groups in your Office 365 tenant, and you need to do a search on a keyword before any groups will appear.

Creating a Device Policy in Office 365 MDM

To create a device policy click the “+” icon in the Device Management section of the Compliance Center.

Give the policy a name and description. You may find it makes administration easier if you name the policy to match the name of the security group it will be targeted to.

The first set of policy items will look familiar to anyone who has configured ActiveSync mobile device policies before. They contain the most common settings that organizations worry about such as requiring a PIN/passcode, requiring a minimum length or complexity for the PIN/passcode, inactive lock timeout, and device encryption.

You’ll also notice the setting to “Prevent jail broken or rooted devices from connecting.” This is not available in ActiveSync policies, only in Office 365 MDM device policies, and it is a good idea to enable it.

We also have options for requiring management of the email profile. This is available on iOS only at this stage, and is what enables selective wipe (only wiping the corporate email data, not any personal data). If the user has an existing email profile on the device that profile will stop working and will need to be deleted so that the managed profile can be applied.

The final setting is to choose whether to block or allow access for devices that do not meet the requirements of your policy (for example a PIN/passcode that isn’t long or strong enough). Remember that anybody in the exception group you configured earlier will not be blocked by this setting. Also keep in mind that users will be blocked for any non-compliance with your new policy, no matter how trivial that particular setting may be in the overall scheme of things. If you want to get a sense of how compliant or non-compliant your users’ enrolled devices are before you start blocking the non-compliant devices then you should set the action below to “Allow access and report violation.”

On the next page are additional security policies that you can configure for backups, data leakage, and application installs. Requiring encrypted backups is a common requirement to protect sensitive data that may be backed up to users computers. Blocking screen capture is one method of making copying or data leakage more difficult (but not impossible).

For demonstration purposes I’m going to enable blocking of the application store in this policy.

Next we can decide whether to apply this policy now or later. I’ve chosen to apply the policy now to a group I created earlier. Again, be aware that the group picker will show no groups at first even if you have groups in your Office 365 tenant, you need to do a search on a keyword before any groups will appear.

Click Next to see a summary of your Office 365 MDM device policy and then click Finish.

The new policy will have a status of “Turning on…” for several minutes, before it displays a status of “On” when it is ready.

Seeing an Office 365 Device Policy in Action

Let’s take a brief look at the new policy in action. Back in the Office 365 admin center in Mobile Devices we can see that there are no managed devices at the moment.

I’ve added the user “Mike Ryan” into the “Standard MDM Policy” group that is targeted by my “Standard MDM Policy” policy. Mike uses an iPhone 4S and has his email account set up in the native Mail app as well as the Outlook app, and is using the OneDrive app to connect to his OneDrive for Business to access documents. He has no other Office Mobile apps installed at this time.

Mike’s native Mail app stops receiving new email, and the next time he attempts to use the Outlook app he receives a login error.

After logging in again Mike is presented with a notice that he needs to enrol the device before he can access any corporate data.

Tapping the “Enrol” button takes Mike to an Intune company portal page instructing him to download the Company Portal app if he doesn’t already have it.

Mike can download the Company Portal app from the iTunes Store (the policy targeted at Mike blocks the app store, but he’s not enrolled yet so he can still access the store), open it, and sign in with his company credentials.

The enrolment process takes a few minutes and there’s several steps where interaction by the user is required (mostly just tapping a button to continue). It’s the type of thing that some users will struggle with, so you would need to have prepared them for this with some communication and educational materials, and have your help desk staff trained up and ready to assist as well.

After Mike’s device has been enrolled he can go back to the Outlook app and sign in again to try and access his email. If there are any issues with his device that make it non-compliant a message will be displayed and he can find out what to do about it.

In this particular case the existing email account for the native Mail app is causing the device to be non-compliant, because the device policy requires that the email profile be managed by Office 365.

Removing the email profile from iOS and waiting a few minutes allows Office 365 MDM to install the managed profile, bringing the device into compliance. The Mail app, Outlook app, and OneDrive app are all able to sign in and access corporate data.

However, all of that would not be very intuitive for a typical end user. I can definitely see that there would be some support required to assist users with enrolment and compliance when Office 365 MDM is being rolled out to an organization. It would certainly be worth considering the less aggressive approach to policy deployment of allowing non-compliant devices to connect and using the compliance reports to identify and remediate as many non-compliant devices as possible before turning on the block controls.

As a final note, by blocking application stores with my device policy Mike is now prevented from installing apps to his device from the iTunes App Store. He didn’t already have the other Office Mobile apps such as Word and Excel installed, and now he can’t install them. You can see that the Company Portal app has sections for publishing company apps as well as apps in public marketplaces like the iTunes App Store, however this Mobile Application Management (MAM) capability is not included in the built-in Office 365 MDM. It is available in the full Intune service though.

Summary

As you can see the process for configuring device policies is not particularly complicated, however there are some important decision points that will impact the user enrolment and ongoing experience in various ways. Thorough testing and piloting is recommended before you begin targeting policies at live users, and less aggressive settings of “allow but report” may be preferable for many deployments.

This article Office 365 Mobile Device Management – Managing Device Policies is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

In this article we’ll look at the user experience for enrolling an iOS device such as an iPhone or iPad for Office 365 Mobile Device Management.

Enrolment can be triggered by an administrator adding the user to a group that is targeted by an Office 365 MDM device policy. An example can be seen here. However it can also be manually initiated by the end user, which is what we’ll look at now.

To begin enrolling a mobile device download the Company Portal app from the App Store.

Open the Company Portal app and sign-in with your corporate username (email address) and password.

After signing in to the Company Portal app tap the “Enroll” button to begin the enrolment process.

Install the management profile when it appears.

If the device has a passcode it will need to be entered now.

After entering the passcode tap “Install” to continue.

Continue to step through the confirmation screens.

When enrolment is complete the Company Portal app will display your device under My Devices. If there is a red warning icon that doesn’t go away after a few moments then there may be a compliance issue with your device.

Tapping the device icon and scrolling down will show you the compliance status, and from this screen you can also reset or remove the device’s enrolment, or force a sync (for example if you have fixed a compliance issue and want to check back in with the server).

This article Office 365 Mobile Device Management Enrolment on Apple iOS Devices is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

At some point in time after you’ve installed an SSL certificate for Exchange Server 2013 you’ll need to renew that certificate. Hopefully you aren’t scrambling to complete this task because your certificate has expired. Most certificate authorities will email you warnings about impending certificate expiry, but the nature of many corporate procurement processes means those reminders often go to some general purchasing team rather than to the technical folks in IT who really need to know about it.

If you’re curious about your current Exchange certificates and their expiry dates you can always run my Exchange certificate report script.

The process for renewing an SSL certificate involves:

1. Generating the renewal CSR
2. Submitting the CSR to the certificate authority (and paying them of course)
3. Installing the certificate that the certificate authority provides to you

An SSL certificate renewal will usually mean you are submitting the CSR to the same CA that you originally acquired the certificate from. If you’re using a different CA this time around you should just generate a new CSR for a brand new certificate instead. Sometimes we just need to switch to a different CA for some reason such as technical issues or customer service.

Note that generating the renewal CSR doesn’t cause any change or interruption to the existing certificate on your server. Also, you do not need to wait until the certificate has expired or is about to expire before you begin the renewal process. Most CAs will add any days still remaining on the certificate to the new certificate as well. For example, if you still have 30 days remaining on your certificate, and you renew it for 1 year, you’ll have 1 year plus 30 days on the new certificate. So renewing your certificate well in advance of it expiring is a good idea since it ensures that you have time to go through any purchasing or payment processes within your organization that may cause a delay.

Open the Exchange Admin Center and navigate to Servers -> Certificates. Select the server that has the expiring certificate and click the Renew link.

Enter the UNC path to a location that the Exchange servers can write to. Typically this will be a network share that has full control permissions granted to the Exchange Trusted Subsystem group, but you can just as easily use one of the system drives on an Exchange server as I’m doing here.

Next, take the CSR info (you can open the .req file in Notepad if you need to copy/paste the contents into a web form) and submit them to your CA (such as Digicert). If you’re unsure of the exact steps check with your CA’s support pages for any instructions. When you’ve downloaded the new certificate place the file somewhere that you’ll be able to access it via UNC path. The same location used to store the certificate request earlier is an easy choice.

In the Exchange Admin Center select the certificate that has the status of “Pending request”, and click the Complete link.

Enter the UNC path to the certificate file and click OK.

The new certificate will appear in the list. If you’ve got multiple certificates with the same name the renewed one can usually be identified as the one with the expiry date further in the future. The new certiifcate may appear enabled for IMAP and POP, which is fine.

Before you enable the new certificate for IIS or SMTP, if you have multiple Client Access servers that are load-balanced with the server you’re currently working with, and therefore all of those load-balanced CAS need the same SSL certificate, you should first export and import the SSL certificate to the other servers.

After you’ve imported the certificate to all of the other servers you can enable the SSL certificate for the necessary services, such as IIS and SMTP.

This article Renewing an SSL Certificate for Exchange Server 2013 is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

ConfigureExchangeURLs.ps1 is a PowerShell script to make it quick and easy to configure the Client Access namespaces on your Exchange servers. The script is designed to apply the same namespace to all Client Access services on the server. You can specify different internal and external URLs. If you have a more complex namespace configuration to apply (for example separate namespaces for each service) then this script does not cater to your scenario, however you can probably adapt it your particular needs.

The script has some mandatory parameters:

• -Server – The name(s) of the server(s) you are configuring.
• -InternalURL – The internal namespace you are using.
• -ExternalURL – The external namespace you are using.

There are some optional parameters as well, if you need them for your configuration. If you don’t use the optional parameters they default to the most common settings in my experience.

• -DefaultAuth – The default authentication method to set for Outlook Anywhere. Defaults to NTLM.
• -InternalSSL – Specifies the internal SSL requirement for Outlook Anywhere. Defaults to True (SSL required).
• -ExternalSSL – Specifies the external SSL requirement for Outlook Anywhere. Defaults to True (SSL required).

You can configure one or multiple servers at the same time. For example, to configure a single server:

.\ConfigureExchangeURLs.ps1 -Server sydex1 -InternalURL mail.exchangeserverpro.net -ExternalURL mail.exchangeserverpro.net

To configure multiple servers:

.\ConfigureExchangeURLs.ps1 -Server sydex1,sydex2 -InternalURL mail.exchangeserverpro.net -ExternalURL mail.exchangeserverpro.net

Download ConfigureExchangeURLs.ps1 from the TechNet Gallery or Github. Questions and feedback are welcome in the comments below.

This article PowerShell Script to Configure Exchange Server Client Access URLs is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

In this article we’ll look at the user experience for enrolling an Android device for Office 365 Mobile Device Management.

Enrolment can be triggered by an administrator adding the user to a group that is targeted by an Office 365 MDM device policy. An example can be seen here. However it can also be manually initiated by the end user, which is what we’ll look at now.

To begin enrolling a mobile device download the Company Portal app from the Google Play store.

The user signs in with their corporate credentials (email address and password).

After signing in tap the Enroll button.

A screen is displayed that lets the user know what enrolment means for the management of the device. Tap Activate to continue.

Tap OK to install the certificate on the device.

After enrolment has completed a list of company apps (if any exist) is displayed in the Company Portal app. The user can tap on My Devices and then the name of the device to verify whether the device is in compliance.

With a compliant device the user can now sign in to applications such as Outlook, OneDrive for Business and Office Mobile.

This article Office 365 Mobile Device Management Enrolment for Android Devices is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Exchange Server 2016 is currently in Public Preview. Do not install preview software in your production environment.

When you first install Exchange Server 2016 it is pre-configured with default URLs for the various HTTPS services such as OWA (Outlook on the web), ActiveSync (mobile device access), Exchange Web Services (the API used for a variety of client communications), and others.

The default URLs contain the fully qualified domain name of the server. So for example if your server name is “exchange01.domain.com” then the default URL for OWA will be “https://exchange01.domain.com/owa“.

These default URLs allow the services to function but they are not suitable for production deployments for several reasons such as:

• They are difficult for end users to remember (this primarily impacts Outlook on the web, where users tend to find it easier to remember a URL such as “webmail.domain.com“)
• A URL containing a specific server name can’t be load-balanced across multiple servers in a high availability deployment
• The internal AD namespace for many organizations is not a valid domain name on the internet, for example domain.local, which makes it impossible to acquire SSL certificates for Exchange 2016 (I’ll cover SSL certificates in a separate article coming soon)

The recommended practice is to change the URLs configured on your Exchange 2016 servers to aliases or generic host names such as “mail.domain.com” after you first install the server.

While there are a variety of namespace designs that apply to different deployment scenarios I will demonstrate here the simplest approach, which is to configure the same namespace (URL) for all services. I’ll be demonstrating with a single Exchange Server 2016 server, but this approach can also be used if you have multiple Exchange servers that you want to load balance (which I’ll cover in a future article).

In my example scenario:

• The server’s real name is demoex16.exchange2016demo.com
• The namespace I’ll be using is mail.exchange2016demo.com
• Internal and external namespaces will be the same

Using my GetExchangeURLs.ps1 script I can see the current configuration of the server.

PS C:\Scripts> .\GetExchangeURLs.ps1 -Server DEMOEX16
----------------------------------------
 Querying DEMOEX16
----------------------------------------
Outlook Anywhere
 - Internal: demoex16.exchange2016demo.com
 - External: demoex16.exchange2016demo.com
Outlook Web App
 - Internal: https://demoex16.exchange2016demo.com/owa
 - External:
Exchange Control Panel
 - Internal: https://demoex16.exchange2016demo.com/ecp
 - External:
Offline Address Book
 - Internal: https://demoex16.exchange2016demo.com/OAB
 - External:
Exchange Web Services
 - Internal: https://demoex16.exchange2016demo.com/EWS/Exchange.asmx
 - External:
MAPI
 - Internal: https://demoex16.exchange2016demo.com/mapi
 - External:
ActiveSync
 - Internal: https://demoex16.exchange2016demo.com/Microsoft-Server-ActiveSync
 - External:
Autodiscover
 - Internal SCP: https://demoex16.exchange2016demo.com/Autodiscover/Autodiscover.xml
Finished querying all servers specified.

In this article we’ll look at:

• Configuring DNS records for the new namespace
• Configuring the namespaces via the Exchange Admin Center
• Configuring the namespaces via PowerShell
• Using a PowerShell script to speed up the configuration of Client Access namespaces

Configuring DNS Records for the Client Access Namespaces

Before changing your server’s namespace configuration you should make sure that the DNS records for the new namespaces already exist in DNS. Some of the virtual directory configuration tasks can fail if the name you specify isn’t resolvable in DNS.

In this example scenario I’ll be using split DNS, which is a recommended practice for Exchange Server 2016 deployments. Split DNS means I will host a DNS zone on my internal DNS servers, and use that to resolve mail.exchange2016demo.com to the internal IP address of my Exchange server (or load balancer if this was a high availability deployment).

Meanwhile, the public DNS zone also has a mail.exchange2016demo.com record that resolves to the public IP address of my firewall or router, which will then NAT any external connections to the Exchange server’s internal IP.

Add the records to both of the zones in your split DNS configuration and make sure they are resolving correctly before you continue.

PS C:\> Resolve-DnsName mail.exchange2016demo.com
Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
mail.exchange2016demo.com                      A      3600  Answer     192.168.0.126

Configuring Exchange Server 2016 Namespaces Using the Exchange Admin Center

After logging in to the Exchange Admin Center in your organization navigate to Servers -> Virtual Directories and select the server you want to configure. There are two approaches you can take. The first is clicking the wrench icon to configure the external namespace for one or more servers.

A window appears that allows you to add one or more servers and specify an external namespace to use.

The outcome of this approach is that all of the external URLs are configured to use that namespace, but the internal URLs remain untouched. This is not ideal for our goal of configuring all services to use the same internal and external namespace.

Instead you can edit the configuration of each virtual directory listed in the Exchange Admin Center by clicking the edit icon.

From here you can edit both the internal and external namespaces for the virtual directory, as well as additional settings such as authentication.

This will achieve the desired outcome, but it is a slow and tedious task. For a single server it would be annoying, for multiple servers it would be downright frustrating. Also, if you ever needed to reconfigure the server you’d need to manually repeat the task.

Instead let’s look at using PowerShell to make the namespace configuration changes.

Configuring Exchange Server 2016 Namespaces Using PowerShell

In a previous article on avoiding server names in SSL certificates I demonstrate how to configure each virtual directory in Exchange Server using PowerShell. You can read that article for a full demonstration but in summary you can run cmdlets such as Set-OWAVirtualDirectory to configure the OWA virtual directory internal and external URLs. Each of the other virtual directories has its own cmdlet for configuring settings, including the Autodiscover virtual directory even though we don’t actually need to configure that one (instead we configure the AutodiscoverServiceInternalUri on the Client Access server).

For example, to configure the same URLs for OWA as shown in the screenshot above:

[PS] C:\>Get-OwaVirtualDirectory -Server DEMOEX16 | Set-OwaVirtualDirectory -InternalUrl https://mail.exchange2016demo.com/owa -ExternalUrl https://mail.exchange2016demo.com/owa

As with the Exchange Admin Center this task can become quite tedious as you move through each virtual directory on every server. But of course if the task can be performed in PowerShell it can be scripted!

Using a PowerShell Script to Configure Exchange Server 2016 Client Access Namespaces

Automating boring tasks is one of PowerShell’s great strengths, and this task is no different. Since every virtual directory (and the Autodiscover service URI) can be configured in PowerShell we can write a script to perform the task quickly.

In your own environment you could manually write out each of the PowerShell commands for your server names and simply save them in a script file. Or you can use my ConfigureExchangeURLs.ps1 script with a few easy to use parameters.

Here’s an example of how I can apply my desired namespace configuration to my Exchange 2016 server using ConfigureExchangeURLs.ps1.

PS C:\Scripts> .\ConfigureExchangeURLs.ps1 -Server demoex16 -InternalURL mail.exchange2016demo.com -ExternalURL mail.exchange2016demo.com
----------------------------------------
 Configuring demoex16
----------------------------------------
Values:
 - Internal URL: mail.exchange2016demo.com
 - External URL: mail.exchange2016demo.com
 - Outlook Anywhere default authentication: NTLM
 - Outlook Anywhere internal SSL required: True
 - Outlook Anywhere external SSL required: True
Configuring Outlook Anywhere URLs
Configuring Outlook Web App URLs
WARNING: You've changed the InternalURL or ExternalURL for the OWA virtual directory. Please make the same change for
the ECP virtual directory in the same website.
Configuring Exchange Control Panel URLs
Configuring ActiveSync URLs
Configuring Exchange Web Services URLs
Configuring Offline Address Book URLs
Configuring MAPI/HTTP URLs
Configuring Autodiscover

Now let’s look at the output of GetExchangeURLs.ps1 again.

PS C:\Scripts> .\GetExchangeURLs.ps1 -Server DEMOEX16
----------------------------------------
 Querying DEMOEX16
----------------------------------------
Outlook Anywhere
 - Internal: mail.exchange2016demo.com
 - External: mail.exchange2016demo.com
Outlook Web App
 - Internal: https://mail.exchange2016demo.com/owa
 - External: https://mail.exchange2016demo.com/owa
Exchange Control Panel
 - Internal: https://mail.exchange2016demo.com/ecp
 - External: https://mail.exchange2016demo.com/ecp
Offline Address Book
 - Internal: https://mail.exchange2016demo.com/OAB
 - External: https://mail.exchange2016demo.com/OAB
Exchange Web Services
 - Internal: https://mail.exchange2016demo.com/EWS/Exchange.asmx
 - External: https://mail.exchange2016demo.com/EWS/Exchange.asmx
MAPI
 - Internal: https://mail.exchange2016demo.com/mapi
 - External: https://mail.exchange2016demo.com/mapi
ActiveSync
 - Internal: https://mail.exchange2016demo.com/Microsoft-Server-ActiveSync
 - External: https://mail.exchange2016demo.com/Microsoft-Server-ActiveSync
Autodiscover
 - Internal SCP: https://mail.exchange2016demo.com/Autodiscover/Autodiscover.xml

Now that the namespaces are configured the next step is to configure an SSL certificate for the server. I’ll cover that in an upcoming article.

Summary

In this tutorial we looked at the default namespace configuration of a newly installed Exchange 2016 server, and discussed why we should configure Client Access namespaces for the server. As you can see there are several methods available for making the configuration changes, with the PowerShell script being the easiest by far. If it is your first time configuring a server it is worth doing the task manually the first time to gain some understanding of what is involved, but if you’re planning to deploy multiple servers then using a script such as ConfigureExchangeURLs.ps1 is highly recommended.

This article Exchange Server 2016 Client Access Namespace Configuration is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

By default an Exchange Server room mailbox does not permit external senders to make bookings. However there is an option that you can configure to allow external senders to make bookings if you need them to.

In this example scenario there are three room mailboxes.

[PS] C:\>Get-Mailbox -RecipientTypeDetails RoomMailbox
Name                      Alias                ServerName       ProhibitSendQuota
----                      -----                ----------       -----------------
HO Meeting Room 1         homeetingroom1       ex2013srv2       Unlimited
Sunset Room               sunsetroom           ex2013srv1       Unlimited
HO Meeting Room 2         homeetingroom2       ex2013srv2       Unlimited

Looking at the “Sunset Room” calendar processing settings we can see that the mailbox is not configured to process external meeting requests.

[PS] C:\>Get-Mailbox "Sunset Room" | Get-CalendarProcessing | Select *external*
ProcessExternalMeetingMessages : False

If an external sender such as a Gmail user attempts to book the meeting room they will not receive an acceptance or rejection message, which may lead to confusion if the room is assumed to have been successfully booked.

To configure the room mailbox to process external meeting requests run the following command:

[PS] C:\>Get-Mailbox "Sunset Room" | Set-CalendarProcessing -ProcessExternalMeetingMessages $true

Note that this change will enable the processing of external meeting requests, but the meeting request is still subject to being accepted/rejected based on availability of the room and any other booking policies you have configured. This change will also only take effect for new meeting requests. Any meeting requests from external senders that were received before the setting was enabled will not be processed.

This article Enabling External Users to Book Exchange Room Calendars is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Exchange Server 2016 communicates with clients, applications and other servers over a variety of network protocols such as HTTPS, SMTP, IMAP and POP. Much of this communication, particularly clients and applications, involves username and password-based authentication. When user credentials are sent over the network they are sent “in the clear”, meaning they can potentially be intercepted and read by an attacker. Other information transmitted during the session may also be sensitive and prone to abuse if interception was possible.

To secure these communications Exchange Server 2016 uses SSL certificates to encrypt the network traffic between the server, clients and applications. This includes:

• Outlook connecting to Outlook Anywhere (RPC-over-HTTP) or MAPI-over-HTTP
• Web browsers connecting to Outlook on the web (OWA)
• Mobile devices connecting to ActiveSync to access mailboxes and calendars
• Applications connecting to Exchange Web Services (EWS) for free/busy and other lookups
• Email clients connecting to secure POP or IMAP
• TLS encrypted SMTP between Exchange servers or other email servers

When Exchange Server 2016 is first installed it generates a self-signed SSL certificate that is then enabled for IIS (HTTPS services like OWA, EWS and ActiveSync), SMTP, POP and IMAP. The self-signed certificate allows the server to be “secure by default” and begin encrypting network communications right from the start, but it is only intended to be used temporarily while you provision the correct SSL certificates for your environment.

When deploying Exchange Server 2016 you should plan to replace the self-signed certificate with a valid SSL certificate for your deployment scenario. This involves an investment of anywhere from $99 to several thousand dollars depending on your Client Access namespace scenario, the type of certificate you purchase, and which certificate authority you purchase it from.

If you’re tempted to stick with the self-signed certificate, or to try and disable SSL requirements on Exchange services, I strongly recommend you do not do those things.

• Deliberately trying to reduce the security of your Exchange environment is unwise
• The hours you’ll spend configuring and troubleshooting your attempted workarounds is more costly than just buying the correct SSL certificate
• Some stuff just flat out won’t work if you try to work around SSL requirements

Exchange Server 2016 SSL Certificate Requirements

There are three basic requirements for an SSL certificate in an Exchange Server 2016 deployment.

• Correct server/domain names – the SSL certificate must contain the namespaces (aka, URLs, aliases, domain names) to match the names that clients will be connecting to (for example, users typing “mail.exchange2016demo.com” in their web browser to access Outlook on the web)
• Certificate validity period – each SSL certificate has a fixed period of time during which it can be considered valid. When the SSL certificate reaches its expiry date it will need to be renewed to continue working.
• Trusted certificate authority – clients will only trust SSL certificates that have been issued by a certificate authority that they already trust. This is one reason that the self-signed certificate is not suitable for general production use, because your clients will not trust certificates issued by the Exchange server itself. There are a wide range of certificate authorities available to purchase certificates from that your client operating systems and devices will trust. I generally recommend using Digicert.

Choosing a certificate authority is simple enough, and the validity period will be determined by how long you purchase the certificate for (usually a minimum of 12 months, but the longer the validity period the less the certificate tends to cost per year). That leaves the server/domain names (or namespaces) as the main decision point when planning your SSL certificates.

Namespaces for Exchange Server 2016 SSL Certificates

The simplest approach to namespaces for Exchange Server 2016 is to use a single namespace for all HTTPS services. An example of this approach can be seen at the following article:

• Exchange Server 2016 Client Access namespace configuration

In addition to the HTTPS namespace it is also common to use a separate namespace for each of the SMTP, POP and IMAP services, although it is certainly not required to do so. There is also the Autodiscover CNAME to consider, and the root domain as well.

In a simple environment where the domain name used for email addresses is exchange2016demo.com, and taking all of the above into consideration, the namespaces could be planned as:

• mail.exchange2016demo.com (for all HTTPS, SMTP, POP and IMAP)
• autodiscover.exchange2016demo.com (for the Autodiscover CNAME)
• exchange2016demo.com (for root domain Autodiscover lookups)

For Exchange Server 2010 to 2016 migration scenarios the certificate may also need to include a legacy name, such as “legacy.exchange2016demo.com”, for the co-existence period. Other than that I am going with the simplest certificate in this example, by using one name “mail.exchange2016demo.com” for HTTPS, SMTP, POP and IMAP.

The recommended practice is to only include aliases as namespaces on SSL certificates, and not any server fully-qualified domain names (real server names). Due to recent changes to certificate issuance rules you may also find it impossible to request an SSL certificate for a domain name that is not internet-routable or that you do not legitimately own (e.g., domain.local). If you’re unsure about how exactly this will work please read my article on avoiding server names in SSL certificates.

Which Type of Certificate to Purchase?

Certificate authorities such as Digicert can sell you a variety of certificate types, and some certificate authorities have different names for what is basically the same thing.

A standard SSL certificate contains a single name and is generally the cheapest to purchase, however these are not suitable for even the simplest of namespace designs.

A wildcard SSL certificate allows you to secure multiple names on a domain without having to specify the exact names on the certificate itself. For example, a Digicert wildcard certificate can be acquired for exchange2016demo.com and *.exchange2016demo.com. While these are often a lower cost option, wildcard certificates can have compatibility issues with some integration scenarios with other systems, as well as not being suitable for secure POP and IMAP configurations.

A SAN or UC (Unified Communications) certificate is the recommended type of SSL certificate to purchase. A SAN certificate can contain multiple names. For example, a Digicert UC certificate can include up to four names at the normal price, with additional names up to 25 total being available at an additional cost. While the cost of a SAN/UC certificate will be more than a wildcard certificate you are less likely to run into any compatibility issues with the SAN/UC certificate, as long as the certificate contains the correct names. If you make an error with your namespace planning or need to add a name later Digicert and some other providers will allow you to re-issue the certificate at no cost, while other providers will charge a re-issuing fee.

How Many SSL Certificates Should You Purchase?

After planning your namespaces and choosing a certificate authority you may be considering how many SSL certificates to purchase, especially if you have more than one Exchange 2016 server.

The recommend practice is to provision as few SSL certificates as possible, because it is simpler to administer as well as less costly to purchase. So while it is possible to have separate certificates for each of the HTTPS, SMTP, POP and IMAP services, it is recommended to use one certificate for all of them unless you have a specific scenario that requires different certificates.

Note that while only one SSL certificate can be enabled for HTTPS on a server, multiple SSL certificates can be enabled for SMTP. However in most simple deployments only a single certificate will be required for SMTP.

Similarly it is recommended to use the same SSL certificate for all of the Exchange servers that will be configured with the same namespaces. For example, if you have two Exchange 2016 servers in a site that will be load-balanced, and both have the “mail.exchange2016demo.com” namespace configured for HTTPS services, they should have the same certificate installed. You achieve this by provisioning the certificate on the first server, and then exporting it and importing it to as many additional servers as needed.

Next Steps

After planning your Exchange Server 2016 SSL certificates the next steps are:

1. Generate a certificate signing request (CSR) for Exchange Server 2016
2. Submit the CSR to your chosen certificate authority
3. Complete the pending certificate request on the Exchange server
4. Export/import the SSL certificate to any additional servers (for multi-server scenarios)
5. Enable the SSL certificate for services in Exchange Server 2016

We’ll explore each of those steps in more detail in upcoming articles on this site.

This article Exchange Server 2016 SSL Certificates is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

One of the great things about Exchange Server is the ability to use PowerShell for a wide variety of administration tasks. And one of the great strengths of PowerShell is the ability to use scripts to automate complex or repetitive tasks to save time, save effort, and avoid errors.

The Exchange Server community has a long history of sharing PowerShell scripts that they have developed so that everyone can benefit from them. Here’s a selection of PowerShell scripts that I think should be in any toolkit.

Note: many of these scripts are developed by individuals in their personal time. If you like a script please let the author know by rating it on the TechNet Script Gallery or leaving a comment on their blog. Similarly, if you find a bug with a script the authors are usually very happy to receive bug reports from the community so that they can fix them.

Exchange Environment Reports

Exchange MVP Steve Goodman wrote this PowerShell script to generate a HTML report that provides an overview of your Exchange environment. I use this script as my first look at any Exchange organization when I am doing support or planning a migration.

Steve’s blog | TechNet Script Gallery

Exchange V15 (2013/2016) Unattended Install Script

Installing the Exchange pre-requisites and building Exchange servers from scratch is a good skill to learn, but after you’ve learned it you will want to automate as much of it as possible. Exchange MVP Michel de Rooij has done just that, maintaining this PowerShell script to install pre-requisites and perform unattended installs of Exchange Server 2013 and 2016.

Michel’s blog | TechNet Script Gallery

Exchange Log Level GUI Script

During a troubleshooting exercise there’s a good chance you’ll increase the diagnostic logging level for several Exchange Server components. Zachary Loeber has put together a PowerShell script that launches a GUI to let you configure the diagnostic levels on your servers.

Zachary’s blog | TechNet Script Gallery

Exchange Mailbox Size and Statistics Report

One of the first PowerShell scripts I wrote many years ago, and have kept updated every since. This script generates a CSV file containing lots of useful stats and information about the mailboxes in your Exchange organization. I use this script when capacity planning and also during migration projects.

Blog post | TechNet Script Gallery

Health Report for Exchange Server 2010/2013 Environments

This PowerShell script can provide you with a health check report for an Exchange Server 2010 or 2013 environment, highlighting issues such as stopped services, unhealthy database replication, or transport queues not processing messages. Run it as a scheduled task for a quick morning health check delivered straight to your inbox.

Blog post | TechNet Script Gallery

Analyze Move Request Performance

During a migration it’s often important to keep an eye on the performance of your migration batches. The Microsoft Exchange Team published this PowerShell script to help you analyze move request performance statistics to identify any causes of poor performance.

Exchange Team blog | TechNet Script Gallery

Monitor Exchange Server Backups

I’ve used this script as a scheduled daily report in every operations role where I was supporting Exchange Server 2007 or later, as well as during every migration project. This script helps you keep an eye on the backup time stamps of Exchange databases to ensure that backups are actually running and completing successfully. Don’t trust your backup software to always tell you the truth, and don’t trust others to always add new databases to the backup schedule when they’re created!

Blog post | TechNet Script Gallery

Compress and Archive IIS Logs

Keep your disk space utilization under control by regularly compressing and archiving the IIS logs on your Exchange Servers.

Blog post | TechNet Script Gallery

Purge Exchange Server 2013 Log Files

If you’d prefer to just purge the log files completely try Thomas Stensitzki’s update to Brian C Reid’s script that removes not only the IIS logs but also the performance and diagnostic logs that Exchange Server 2013 generates automatically.

Brian’s blog | Thomas’ blog | TechNet Script Gallery

Check Your RBAC Role Group Membership

Keeping a close eye on role group membership in an Exchange environment is important to maintain least-privilege access for the different teams in your organization. This PowerShell script will export the membership of each role group so you can verify who has access to what, and extra info such as whether they have any passwords that haven’t been changed in a long time.

Blog post | TechNet Script Gallery

Generate File-System Antivirus Exclusions List for Exchange Server 2013

Antivirus software is a leading cause of unplanned database failovers in an Exchange environment. This PowerShell script generates the list of file, folder and process exclusions to add to the antivirus configuration on an Exchange server, based on Microsoft’s recommended practices.

Blog post | TechNet Script Gallery

Audit RDP Connections for your Servers

Ever wanted to know who has been logging on to your Exchange servers using RDP? Exchange MVP Mike Crowley has published this script so you can run a report any time you like.

Mike’s blog | TechNet Script Gallery

Check your Exchange Server SSL Certificates

Expiring SSL certificates can cause a lot of problems in your Exchange environment, so it’s a sensible idea to check them as part of your routine maintenance and health checks. I also use this script any time I am auditing a new environment for a troubleshooting case or a migration project.

Blog post | TechNet Script Gallery

Report on Mailbox Permissions

I frequently see people looking for scripts to help them gain some visibility of the mailbox permissions in their Exchange organization. Serkan Varoglu has published this PowerShell script that lets you produce a report of the mailbox permissions for a mailbox, a database, or the entire organization.

TechNet Script Gallery

ActiveSync Device Statistics Report

As staff come and go in your organization the Exchange environment tends to accumulate stale mobile devices. This PowerShell script will generate a report of mobile devices that have not synced in a specified number of days. You can also use it to look at details such as which makes and models of mobile devices your users are connecting with. The report is generated in CSV and HTML email formats.

Blog post | TechNet Script Gallery

Recipient Address Report

Mike Crowley wrote this script to produce a report of every recipient’s SMTP proxy addresses, which is very useful in a wide range of migration and management scenarios.

Mike’s blog | TechNet Script Gallery

Update Calendar Folder Permissions

Exchange MVP Lasse Pettersson takes the guesswork out of whether you need to run Set-Mailboxfolderpermission, Add-Mailboxfolderpermissions, or Remove-Mailboxfolderpermission, by combining it all into one script that lets you add, update or remove permissions on mailbox folders.

Lasse’s blog | TechNet Script Gallery

What’s Missing?

Do you know of a useful PowerShell script that Exchange admins should know about? Feel free to add a comment below.

Note, please don’t paste entire script contents into the comments below. Publish your script to TechNet, Github, or elsewhere if you want to share it with the community.

This article PowerShell Scripts for Your Exchange Server Toolkit is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com