Identifying IIS Worker Process in Exchange 2013/2016

It might come a time when troubleshooting performance issues where we need to identify exactly what a particular IIS Worker Process is in an Exchange 2013 environment:

First thing we need to do is get the Process ID (or PID). To do this, right-click on one of the columns and select PID:

We can now see that that PID for the IIS Worker Process we are trying to identify is 10300:

Now open a Command line or PowerShell console, navigate to Windows\System32\Inetsrv and then run the command “appcmd list wp” or “.\appcmd list wp” if you are using PowerShell:

We now know that the IIS Worker Process with the PID of 10300 is the Exchange OWA Application Pool.

Message Tracking Logs Missing

The other day someone asked me for help regarding Message Tracking Logs missing. The problem was that the person had the message tracking logs configured to save 60 days’ worth of data but he could not find a particular email that was supposedly delivered before those 60 days.

 

The first step was to verify that 60 days of logs were actually being saved:

Get-TransportService | Select MessageTrackingLogMax*
MessageTrackingLogMaxAge:           60 Days
MessageTrackingLogMaxDirectorySize: 1000 MB
MessageTrackingLogMaxFileSize:      10MB

Going to the location where the logs are saved (by default %ExchangeInstallPath%TransportRoles\Logs\MessageTracking), there were indeed 60 days’ worth of logs, so why couldn’t we find the email?! Also, the overall folder size was over 1GB in size... But how can that be if we specified to only use 1000MB?! Let us go back a bit first...

 

The naming convention for message tracking log files in Exchange 2013 is MSGTRKyyyymmdd-nnnn.log, MSGTRKMAyyyymmdd-nnnn.log, MSGTRKMDyyyymmdd-nnnn.log and MSGTRKMSyyyymmdd-nnnn.log . The different logs are used by the following services:

• MSGTRK: these logs are associated with the Transport service;
• MSGTRKMA: these logs are associated with the approvals and rejections used by moderated transport;
• MSGTRKMD: these logs are associated with messages delivered to mailboxes by the Mailbox Transport Delivery service;
• MSGTRKMS: these logs are associated with messages sent from mailboxes by the Mailbox Transport Submission service.

 

The placeholders in the log file names represent the following information:

• The placeholder yyyymmdd is the coordinated universal time (UTC) date on which the log file was created. Yyyy = year, mm = month and dd = day;
• The placeholder nnnn is an instance number that starts at the value of 1 daily for each message tracking log file name prefix.

 

Information is written to each log file until the file size reaches its maximum specified value (MessageTrackingLogMaxFileSize) for each log file. Then, a new log file that has an incremented instance number is opened. This process is repeated throughout the day. The log file rotation functionality deletes the oldest log files when either of the following conditions is true:

• A log file reaches its maximum specified age;
• The message tracking log directory reaches its maximum specified size.

 

Now here comes the important part! The maximum size of the message tracking log directory is calculated as the total size of all log files that have the same name prefix. Other files that do not follow the name prefix convention are not counted in the total directory size calculation.

On Exchange 2013 Mailbox servers, the maximum size of the message tracking log directory is three times the specified value. Although the message tracking log files that are generated by the four different services have four different name prefixes, the amount and frequency of data written to the MSGTRKMA log files is negligible compared to the three other log file prefixes.

 

Going back to the initial issue, the problem was that there were less than 60 days’ worth of MSGTRKMD logs as the combined log files size has met the 1000 MB limit...

So, the bottom line is that, as with Exchange 2010, if you want to keep X amount of days of message tracking logs, ensure you set MessageTrackingLogMaxDirectorySize to a high enough value.

How to Bypass the Clutter in Exchange Online

Clutter is a feature in Office 365 designed to help users focus on the most important messages in their Inbox by moving lower priority messages out of their way and into a new Clutter folder. Exchange Online keeps track of the emails users read and the ones they don't read. Once it is turned it on, Clutter is automatic. As new email comes in, it takes messages users are most likely to ignore and puts them into the Clutter folder. The more users use it, the better it gets.

For organizations, it is important to ensure that certain messages do not end up in users’ Clutter folders. These could be messages from the CEO, from the HR or Finance departments, from the ServiceDesk, etc. In order to ensure this is the case, we need to create a transport rule that makes sure that these messages bypass the clutter folder.

We can do this by using PowerShell to create a rule similar to the following for example:

New-TransportRule -Name “Bypass Clutter” –From servicedesk@nunomota.pt -SetHeaderName “X-MS-Exchange-Organization-BypassClutter” -SetHeaderValue “true”

Please note that both “X-MS-Exchange-Organization-BypassClutter” and “true” are case sensitive!

If we prefer to use the UI, the transport rule will look like this:

Office 365 Support and Recovery Assistance tool

If you are experiencing problems with Outlook or are having trouble installing Office apps, Microsoft's new Office 365 Support and Recovery Assistant tool (aka SaRA) can help diagnose and fix many common user or client side issues.

The tool performs a series of diagnostics tests to help identify the root cause of issues, such as verifying users’ credentials, licenses, updates to Outlook clients, and whether Outlook servers are reachable. Depending on the test results, it can offer to automatically fix problems for users or provide instruction on recommended solutions. All the diagnostics results are saved in a log file for users to share with their Outlook admin or support engineers for further investigation.

Each time we run SaRa, it automatically gets updated to its latest version, so it can troubleshoot any new Outlook problems.

SaRA, still in the pre-release (beta) stage, can be downloaded from this link: http://aka.ms/snrpublic

How to determine which store worker process is responsible for which mailbox database?

As we all know by now, the Exchange Store service in Exchange 2013 has been rewritten in such a way that each database now runs under its own process, thus preventing store issues to affect all databases in the server. Managed Store is the new name for the rewritten Information Store process (store.exe). It is now written in C#, designed to enable a more granular management of resources (additional I/O reduction, for example) and is even more integrated with the Exchange Replication service (MSExchangeRepl.exe), in order to provide a higher level of availability.

The database engine continues to be ESE, but the mailbox database schema itself has changed in order to provide many optimizations.

The Managed Store is composed of two processes. The first one is the Store Worker Process (Microsoft.Exchange.Store.Worker.exe) that is similar to the old store.exe process. The difference is, as already mentioned, that there is one Store Worker Process for each database. This means that if one of these processes fails, only the database it is responsible for will be affected, while all the other databases will remain operational.

The second one is the Store Service Process (Microsoft.Exchange.Store.Service.exe) that controls all store worker processes. For example, when a database is mounted, the store service process will start a new store worker process for that particular database. On the other hand, when a database is dismounted, it will terminate the store worker process responsible for that database.

The question that sometimes arises is “how do we determine which store worker process is responsible for which mailbox database?” To show how to do this, I am going to use a test server where I have 2 mailbox databases, and therefore two Microsoft.Exchange.Store.Worker.exe):

First thing we need to do is get the Process ID (or PID). To do this, right-click on one of the columns and select PID:

 

 

We can now see that that PID for the store worker we are trying to identify is 3308:

 

Now open an Exchange Management Shell console and run the following cmdlet:

Get-MailboxDatabase -Status | Sort Name | FT Name, WorkerProcessID

 

We now know that the store worker process with the PID of 3308 is responsible for the mailbox database DB01.

How to Generate Exchange OAB Multiple Times a Day

The generation of the Offline Address Book (OAB) back in Exchange 2010 was based on a schedule set on the OAB’s properties. In Exchange 2013 (at least in CU9 at the time of writing this) and in Exchange 2016 "beta" we still see this property but it is no longer used:

 

 

Instead, Exchange Server 2013 OAB Generation takes place according to OABGeneratorWorkCycle and OABGeneratorWorkCycleCheckpoint properties configured at the Mailbox Server. According to TechNet:

• The OABGeneratorWorkCycle parameter specifies the time span in which the OAB generation on the Mailbox server will be processed. The default value is 8 hours;
• The OABGeneratorWorkCycleCheckpoint parameter specifies the time span at which to run OAB generation on the Mailbox server. The default value is 1 hour.

 

 

Maybe it is because English is not my first language, but it took me a while to understand exactly what the above means... Eventually I got to the conclusion that what the above text is trying to tell us is that, by default, Exchange updates the OAB every 8 hours. If I look at my environment, I can see this is indeed the case:

 

 

For organizations where recipients change at a considerable rate, this might not be ideal. Let us say that we want to want to update the OAB every 2 hours instead. To achieve this, we simply run the following cmdlet:

Set-MailboxServer “server” -OABGeneratorWorkCycle 00.02:00:00 -OABGeneratorWorkCycleCheckpoint 00:30:00

 

 

 

After a few hours, we can check the Application log and look for Event ID 17002 to ensure the OAB is actually being generated every two hours (Event ID 17001 shows when the generation started while 17002 when it completed):

 

 

 

Don’t forget that to set these properties across all your Mailbox servers that might be generating the OAB. The server hosting the arbitration mailbox with Persisted Capability “OrganizationCapabilityOABGen” is the one responsible for the OAB generation. For a non-DAG environment, you can use the following cmdlet to identify the OAB Generation server:

Get-Mailbox -Arbitration | Where {$_.PersistedCapabilities -match "oab"} | FT Name, ServerName

For a DAG environment, use the following one instead:

Get-Mailbox -Arbitration | Where {$_.PersistedCapabilities -match "oab"} | FT Name, Database

And then check which server currently has that database mounted:

Get-MailboxDatabaseCopyStatus “database”

Unable to see multiple Organizational Units in Exchange 2013 EAC

On a new Exchange 2013 CU8 environment that I am currently working on, we experienced an issue with the Exchange Admin Center (EAC): when creating a new mailbox for a new user and trying to select the OU where the user should be create, we were unable to see some OUs.

 

It turns out that, by default, the EAC only displays 500 OUs to optimize EAC’s performance. However, in this environment there are over 900...

 

The solution was to edit the web.config file for the ECP. On a CAS server, this is located by default at C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ecp, while on a Mailbox or multi-role server it is at

C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp.

 

Once you locate the file, open it in Notepad with Admin rights, locate the <appsettings> section and add the following key:
<add key="GetListDefaultResultSize" value="1000">

Obviously, if you have more than 1000 OUs, simply increase the value.

When this is done, go to IIS and recycle the MSExchangeECPAppPool application pool. Reopen the EAC and you will now be able to see all OUs in your organization. Just do not forget to change this setting across all your servers otherwise the behaviour might be inconsistent.

Fatal error TooManyMissingItemsPermanentException has occurred

During a recent transition from Exchange 2010 to 2013, a user’s mailbox failed to get migrated:

[PS] C:\>Get-MoveRequestStatistics “nuno mota”

DisplayName          StatusDetail

-----------          ------------

Nuno Mota            FailedOther

 

Ok, “FailedOther” does not provide much information... Let us get a report of the actual move request to try to find out exactly what happened:

[PS] C:\>Get-MoveRequestStatistics “nuno mota” -IncludeReport | FL

(...)

7/13/2015 10:40:23 AM [server1] A missing item was encountered: Missing Item (IPM.Note.EnterpriseVault.Shortcut) Subject:"Tania   resume", Folder:"Outbox"

 

7/13/2015 10:40:23 AM [server1] A missing item was encountered: Missing Item (IPM.Note.EnterpriseVault.Shortcut) Subject:"Netting Off entry 2011 March  28", Folder:"Outbox"

 

7/13/2015 10:40:23 AM [server1] A missing item was encountered: Missing Item (IPM.Note.EnterpriseVault.Shortcut) Subject:"Data for weekly report -  11/March/2011", Folder:"Outbox"

 

7/13/2015 10:40:23 AM [server1] A missing item was encountered: Missing Item (IPM.Note.EnterpriseVault.Shortcut) Subject:"FW: 2011 JAN ANALYSIS  revised based on ultimate parent name", Folder:"Outbox"

 

7/13/2015 10:40:23 AM [server1] A missing item was encountered: Missing Item (IPM.Note.EnterpriseVault.Shortcut) Subject:"PAYMENT RECONCILIATION  as on 16/2/2011", Folder:"Outbox"

 

7/13/2015 10:40:23 AM [server1] A missing item was encountered: Missing Item (IPM.Note.EnterpriseVault.Shortcut) Subject:"PORTFOLIO CAL  ACC _EOP  LIST CALCULATION   as on 07/01/2011", Folder:"Outbox"

 

7/13/2015 10:40:24 AM [server1] Mailbox contents verification complete: 139 folders, 254510 items, 2.829 GB (3,037,189,613 bytes).

 

7/13/2015 10:40:25 AM [server1] Stage: FinalIncrementalSync. Percent complete: 95.

 

7/13/2015 10:40:25 AM [server1] Fatal error TooManyMissingItemsPermanentException has occurred.

 

 

Ok, so from the output above we can have a clearer view of what is happening. At the end of the report we see a TooManyMissingItemsPermanentException error is preventing Exchange from completing the move request, and the reason for that is all the EnterpriveVault stubs that seem to be missing from the mailbox’s Outbox folder.

 

When we create a mailbox move request, or batch, we can use the BadItemLimit parameter to specify the maximum number of bad items that are allowed before the request fails. A bad item is a corrupt item in the source mailbox that cannot be copied to the target mailbox. However, also included in the bad item limit are missing items. Missing items are items in the source mailbox that cannot be found in the target mailbox when the request is ready to complete.

 

So, if we are comfortable ignoring this error and possibly leaving a few bad items behind, we can either increase the BadItemLimit by running:

Set-MoveRequest “nuno mota” –BadItemLimit 50

Resume-MoveRequest “nuno mota”

 

Valid input for BadItemLimit is an integer or the value unlimited. The default value is 0, which means the request will fail if any bad items are detected. If you set this value to 51 or higher, you also have to use the AcceptLargeDataLoss switch, otherwise the cmdlet will fail.

If too many bad items are detected, consider using the New-MailboxRepairRequest cmdlet to attempt to fix corrupted items in the source mailbox, and try the request again.


Alternatively, we can update the ContentVerificationMissingItemThreshold setting in the MsExchangeMailboxReplication.exe.config file which in Exchange 2013 is located by default at C:\Program Files\Microsoft\Exchange Server\V15\Bin.

If you opt for changing this setting, you have to restart the restart Microsoft Exchange Mailbox Replication service and then resume the move request as above.

Exchange ActiveSync v16 is coming!

The last major version of Exchange ActiveSync (EAS) was v14 which came as part of Exchange 2010 (EAS v14.1 came with Exchange 2010 SP1). Almost 6 years after it is now time for an update to EAS and the release of a new version, v16.

 

At the time of writing this tip, it is unclear if EAS v16 will be part of Exchange 2016... Like with other features, Microsoft will be releasing it first to Office 365 and then eventually enable it in the on-premises Exchange 2016 builds...

 

This new version of EAS is planned to contain three new major capabilities:

1. Improved calendar reliability by reworking the calendar workflow. This will most likely go unnoticed by most end users but will, hopefully, help with those appointment nightmares some Exchange admins experience with 3^rd-party mail clients;
2. Calendar attachments. While currently calendar items synchronized with EAS cannot include attachments such as agendas, presentations or spreadsheets, in version 16 these will also sync;
3. The drafts folder cannot be synced with the current version of EAS, but it will be in EAS v16. This means we can start composing an email on our EAS device and continue editing it on our desktop, for example, or vice-versa.

To check which ActiveSync protocol versions your Exchange Online mailbox supports, go to https://testconnectivity.microsoft.com and run the Exchange ActiveSync test from the Office 365 tab. From the test’s output, look for MS-ASProtocolVersions:

 

Like with previous EAS version changes, v16 will require the client to support it. It seems that iOS 9 will at least support the calendar features when it is released this fall.

 

As always, please note that the information provided here might change when EAS v16 is released.

Exchange Management Shell and Active Directory

Working in multi-domain / multi-site environments can sometime be tricky if we don’t know how the Exchange Management Shell (EMS) queries Active Directory (AD) in these scenarios.

In Exchange 2013 and 2010, we can use the Set-AdServerSettings cmdlet to manage the Active Directory Domain Services (ADDS) environment in the current EMS session. This cmdlet cmdlet replaces the AdminSessionADSettings session variable that was used in Exchange 2007 (which we will look at in a minute).

The following example specifies that all recipients in the entire forest can be viewed and managed (by default, only those in the local domain are used):

Set-AdServerSettings -ViewEntireForest $True

The following example sets the recipient scope to the IT Users OU in the nunomota.pt domain for the current session:

Set-AdServerSettings -RecipientViewRoot “nunomota.pt/IT Users”

The following example sets the scope of the current session to the entire forest and designates dc1.nunomota.pt as the preferred global catalog server.

Set-AdServerSettings -ViewEntireForest $True -PreferredGlobalCatalog dc1.nunomota.pt

The following are the most common parameters that administrators change:

• PreferredGlobalCatalog: specifies the FQDN of the global catalog server to be used for reading recipient information in this session;

• PreferredServer: specifies the FQDN of the domain controller to be used for this session;

• RecipientViewRoot: specifies the OU to include in the recipient scope for this session. When we specify a recipient scope with this parameter, only the recipients included in the scope are returned;

• ViewEntireForest: when we specify a value of $true, the value stored in the RecipientViewRoot parameter is removed and all of the recipients in the forest can be viewed and managed.

As already mentioned, in Exchange 2007 we had a variable named $AdminSessionADSettings for this purpose. To achieve the same as the examples above, all we have to do is update this variable as follows.

The following example specifies that all recipients in the entire forest can be viewed and managed (by default, only those in the local domain are used):

$AdminSessionADSettings.ViewEntireForest = $True

The following example sets the recipient scope to the IT Users OU in the nunomota.pt domain for the current session:

$AdminSessionADSettings.DefaultScope = “nunomota.pt/IT Users”

To set the recipient scope to the nunomota.pt domain and use dc1.nunomota.pt as the recipient domain controller, run the following commands:

$AdminSessionADSettings.DefaultScope = “nunomota.pt”

$AdminSessionADSettings.PreferredDomainControllers = “dc1.nunomota.pt”

Changing the recipient scope in the EMS changes the set of recipients that are returned for the Get- cmdlets of the recipient. The fields that are stored in the $AdminSessionADSettings variable are retained until the EMS is closed and is reset to its default settings the next time that the EMS is opened.

To make the changes permanent, we have to manually edit the Bin\Exchange.ps1 file in the Exchange Server installation folder and update lines such as:

$global:AdminSessionADSettings.ViewEntireForest = $false

How to Convert a Distribution List into a Mailbox

Sometimes, an organization/administrator might have the need to convert a Distribution Group (DG) (or Distribution List) into a normal mailbox or a shared mailbox. Reasons for this vary, but the most common one is when an organization has the need to start sending emails as that DG.

 

Unfortunately, there is no native way of achieving this. But it is completely achievable and straightforward. The best way is to:

1. Write down the DG’s LegacyExchangeDN. To do so, you can run the cmdlet: Get-DistributionGroup “DG_name” | Select LegacyExchangeDN;
2. Delete the DG;
3. Create a (shared) mailbox with the same SMTP address;
4. Add the DG’s legacyExchangeDN as an X500 address to the new mailbox.

I am not going into detail of what the legacyExchangeDN is and how or why it is used as this is already well documented all over the Internet. As a quick overview, the auto-complete cache in Outlook and in OWA uses the value of the legacyExchangeDN attribute to route email messages internally. If the value changes, the delivery of email messages may fail with a 5.1.1 NDR.

 

If you already deleted the DG and have no way of retrieving its legacyExchangeDN, you have two options:

1. Clear the auto-complete cache (straightforward but most of the times not the best approach);
2. Manually create an X500 proxy address for the old legacyExchangeDN attribute for the DG.

To create an X500 proxy address, you need to use an NDR you have received when emailing the DG, which should contain the recipient’s address such as:

IMCEAEX-_O=LetsExchange_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29_CN=RECIPIENTS_CN=f6a32c0ab0e64f33b2a7b3f9a48c2da6@nunomota.pt

From here, make the following changes based on the recipient address in the NDR:

• Replace any underscore character (_) with a slash character (/);
• Replace “+20” with a blank space;
• Replace “+28” with an opening parenthesis character;
• Replace “+29" with a closing parenthesis character;
• Delete the “IMCEAEX-“ string;
• Delete the “@nunomota.pt” string;
• Add “X500:” at the beginning.

After you make these changes, the proxy address will look similar to:

X500:/O=LetsExchange/OU=Exchange Administrative Group (FYDIBOHF23SPDLT)/CN=Recipients/CN=f6a32c0ab0e64f33b2a7b3f9a48c2da6

Create Folder on Users’ Mailboxes

One could think that the Exchange Online and Exchange 2013 New-MailboxFolder cmdlet would allow administrators to create folders on other users’ mailboxes. Unfortunately this is not the case...

 

Basically RBAC (Role Based Access Control) only allows the administrator to run this cmdlet on the mailbox it owns. As we can see below, RBAC has an implicit recipient read and write scope set to Self:

 

So can we create a new role based on MyBaseOptions and update the ImplicitRecipientReadScope to OrganizationConfig? Once again, unfortunately no... You see, if you read the Understanding management role scopes TechNet article, it states that:

 

“You can't change the implicit scopes defined on management roles. You can, however, override the implicit write scope and configuration scope on a management role. When a predefined relative scope or custom scope is used on a role assignment, the implicit write scope of the role is overridden, and the new scope takes precedence. The implicit read scope of a role can't be overridden and always applies.”

 

By the way, the exact same thing applies to the Get-MailboxFolder cmdlet... The good news for this cmdlet is that we can simply use the Get-MailboxFolderStatistics cmdlet to list all folders in any mailbox we want.

 

 

So, as far as I know, there is nothing we can do to make this cmdlet work for other mailboxes the administrator does not own. So is there a way to create folders for other users? Yes, using Exchange Web Services (EWS) script!    :)

 

I have written a few EWS scripts to perform certain actions on mailboxes that are not possible using the native Exchange cmdlets. To achieve this, I am not going to re-invent the wheel as there is already a great script by David Barrett to do exactly what we want. For more information on his script, please check his blog article PowerShell: Create folders in users' mailboxes.

Exchange 2013 EAC Performance Console

Almost 3 years ago, on my Exchange 2010 ECP Performance Console article on MSExchange.org, I explored the Performance Console of the Exchange Control Panel in Exchange 2010. Did you know that this console is still present in Exchange 2013?

 

This console, which is not visible by default, provides numerous counters regarding the performance of the EAC. We can use it to check how long it takes to authenticate a user, how many PowerShell cmdlets have been invoked and even how long the server took to process requests, and much more.

 

To enable it, we have to manually edit the web.config file located at:

%ExchangeInstallPath%\V15\ClientAccess\ecp\web.config

 

Open the file with Notepad and look for the "appSettings" section, right in the first few lines. In there we will find the following key:

 

<!-- Set ShowPerformanceConsole to "true" to show ECP's Perf Console: -->
<add key="ShowPerformanceConsole" value="false" />

 

 

As the comment explains, all we have to do to enable the console is update the value of the ShowPerformanceConsole key from false to true. Save the file, run the usual IISRESET /NOFORCE to restart IIS and we are good to go!

 

If we now log in to the EAC, we will have a Performance console link:

 

Clicking on this link opens the console itself:

 

 

To learn more about this console, check my Exchange 2010 ECP Performance Console article at MSExchange.org.

Updating AADSync Scheduled Task

If you ever need to update AADSync’s scheduled task, it is likely that you will need to update the credentials it runs under. When you do that, and if you do not assign the correct permissions, you might get the following error message:

 

This is because the account used does not have the required permissions. Make sure you add it to the local Admins group and to the local ADSyncAdmins group.

Exchange 2013 Performance Health Checker Script

Microsoft has just published the Exchange 2013 Performance Health Checker script, which checks various configuration items on Exchange 2013 servers to make sure they match the recommendations published in the “Exchange 2013 Sizing and Configuration Recommendations” guidance on TechNet. It also reports on OS, system and hardware information. It can be ran remotely, against a single server or a group of servers.

 

The script takes some of the most common configuration causes of Exchange 2013 performance cases that Microsoft has encountered in support and allows administrators to rule them out quickly without having to check each server or read through the entire TechNet guidance.

 

 

The current list of items the script reports on is:

• Operation System version
• Exchange Build
• Physical/Virtual Machine
• Server Manufacturer and Model (physical hardware only)
• VM host processor/memory configuration recommendations
• Exchange server roles
• Pagefile Size
• Power Settings
• .NET Framework version
• Network card name and speed
• Network card driver date and version (Windows 2012 and Windows 2012 R2 only)
• RSS enabled (Windows 2012 and Windows 2012 R2 only)
• Physical Memory amount
• Processor Model
• Number of processors, cores, and core speed
• Hyper-threading enabled/disabled
• Processor speed being throttled
• Current list of active/passive databases and mailboxes (optional)

 

Let us look at some examples. First, we run the script without any parameters, meaning it will check the local server. We could use the –Server parameter to run it against a remote server.

By including the –MailboxReport parameter, the script presents some statistics around mailboxes and databases:

Another useful parameter is –LoadBalancingReport which looks at all CAS servers to determine how user connections are being load balanced across these servers. We can use the -CasServerList to specify which CAS servers we want to check.

Every time the script runs, it outputs the results to a log file as mentioned at the end of every output. In the next screenshot we can see the report from the cmdlet above:

Office 365 Compliance Center

The new Compliance Center contains the key compliance-related features for an Office 365 administrator to manage compliance across Office 365, Exchange Online and SharePoint Online.

 

Currently many of the compliance features are still accessible through service-specific management interfaces, such as the Exchange Admin Center. However, this will change in the future as more service independent compliance features are added to the Compliance Center.

 

Consolidating compliance functionality across services into this single area will make compliance features easier to access and enhance your end-to-end task-based experience.

 

To access the Compliance Center you can either go directly to its URL at https://compliance.protection.outlook.com/Ucc or, if you are an Office 365 administrator:

1. Sign in to Office 365;

2. Select the app launcher icon in the upper-left and choose Admin:

 

3. In the lower-left navigation, expand Admin and choose Compliance:

 

4. You are then taken into the new Compliance Center:

 

 

As mentioned, this is currently being rolled out so it is possible that you will not see all the features in here just yet. For example, there will be an Auditing section as well which is not yet present in my tenant.

 

Stay tuned for a full article on the new Office 365 Compliance Center!