close

Exchange 2013

Exchange 2013

Replacing permissions on Public Folder Trees

02-03-2020-473-Replacing-permissions-on-Public-Folder-Trees-LOW

You wouldn’t expect that in 2020 we would still be trying to manage Public Folders in Exchange, especially given that people originally expected them to die a death nearly fourteen years ago, with Exchange 2007.
Unfortunately, they’re still around and as Exchange 2010 lives beyond the grave, with its life-support extended until October 2020 you, like many others, are trying to get rid of Public Folders or move them to modern Exchange or Office 365.
One common ask is to be able to quickly replace a set of Public Folder permissions on Exchange 2010. There are scripts from Microsoft to do this on Exchange 2013 and above, but not a quick and simple one for Exchange 2010. To help with this requirement for one of my customers, I’ve written a simple script that can be used to achieve this.
The ReplacePFPermissions script is a simple script that enables you to remove non-default permissions from a Public Folder and it’s sub-folders and add a new Public Folder permission – such as a group, or perhaps an admin account if you are removing general user access.

One common problem you may be trying to solve (and failing) is removing permissions that aren’t identified as problematic by the Source Side Validation scripts provided by Microsoft. For example, you might find some recently deleted users, or users who are not mailbox-enabled still have Public Folder permissions, as shown below:

Public Folder Trees permissions

I’ll cover a quicker way of performing a search and destroy for these type of issues in my next article on the subject, but if you want to perform a clean of a Public Folder tree and remove spurious permissions that should not be there, then using the ReplacePFPermissions script may help.

To use the script, download it from my GitHub. In the example below, I’m going to replace the existing permissions with a Mail-Enabled Security Group, called PFPGroup. I’ll give this group Owner permissions down the tree, starting from a folder called TopLevel.

The structure looks like this screenshot below, with each folder having a mix of different permissions added:

Public Folder Trees properties

Before I replace the permissions, I will want to test the script to see which permissions will be removed. It is, obviously, crucial to validate what damage any script you run will perform in case you review the changes and find that it will cause you problems.

In the example below, I use the TestMode parameter with the script:

The output will show the “WhatIf” output from the Remove-PublicFolderClientPermission cmdlets that will be ran:

Remove public folder client permission

For safety’s sake I’ll also recommend running the Start-Transcript cmdlet to ensure you have a handy log of script output as well.

As I am reasonably happy with the above output, I’ll run the script again with the TestMode parameter removed:

You’ll see below a much simpler output – only errors will be shown, should one occur.

Errors returned

Examining the Public Folders in the EMC now will show that the PFPGroup has replaced all of the custom permissions:

Public folder management console

You will note that I’ve chosen to leave any Anonymous and Default permissions intact.

Source Practical365

 

read more
Exchange 2013

Why Exchange admins should be very worried

10-02-2020-457-Generic-Image-Generic-images-of-podcast-computers-mailbox-migrations-LOW

If you haven’t already done so, this week you should be applying patches to your Exchange Servers. A reasonably easy to exploit vulnerability has been disclosed by Microsoft as CVE-2020-0688.
Sigi and I talked about this in this week’s episode of The Practical 365 podcast, but this is important enough to write about separately in case you missed the show.
The TL:DR version of this is – anyone with the username and password for a mailbox on your Exchange Server and access to the /ecp directory can execute code as the SYSTEM account on the server itself.
The proof-of-concept exploits show this can be achieved by sending it an easily crafted URL using freely obtained open source tools.
This vulnerability is due to Microsoft using the same set of cryptographic keys on every Exchange Server installation. The keys being stored in plain text in a web.config file on every server.
The bad news is that although it has taken nearly ten years for this to be noticed, now it has, would be attackers are acting quickly. Security researchers are already seeing scans for public-facing Exchange servers to obtain build version information. If you publish OWA and ECP externally the next step by these malicious people will be to attempt to gain a set of working credentials to access Exchange. There are already tools available to use social networks like LinkedIn to harvest email addresses and of course tools to automate login attempts.
Make no mistake – if you publish Exchange externally and don’t patch, it’s only a matter of time until this is exploited.
Even if you don’t publish Exchange externally, you should consider this a threat. Not all staff follow the rules and it’s possible an insider within your organization may use this opportunity to take advantage of the rights an Exchange computer account has. The amount of damage someone could do easily shouldn’t be understated.
Find out more: Working with the new Exchange cmdlets
Simon Zuckerbraun, of the Zero Day Initiative, has produced a comprehensive write-up on their blog that provides a vast amount of detail about the vulnerability including a walk-through on how to exploit it. It makes for worrying reading – all an attacker needs is a compiled version of ysoserial.net, the validation key from either his article – or any Exchange Server– and then by crafting a URL GET request to /ecp/default.aspx they can do as they wish. If that hasn’t worried you yet, read the article now.

Getting patches for Exchange

Patches are available for all support versions of Exchange Server – from 2010 through to 2019 and all are affected.

The update comes in the form of an Update Rollup, UR30, for Exchange 2010, and security updates for the latest Cumulative Updates for Exchange 2013, 2016 and 2019. If you aren’t running the latest CUs for Exchange 2013 or higher, then you will need to get current as well as subsequently applying the patch.

Source Practical365

read more
Exchange 2013

Spotify Preparing to Introduce Integrated Voice Commands

spotify-redesign-official-768×432

Voice assistants like Google Assistant and Alexa can tap directly into Spotify to allow users to control the app through voice commands. However, Spotify wants users to be more integrated with the streaming service. As such, the company is developing its own in-house assistant that will work within Spotify.

App researcher Jane Manchun Wong discovered information that shows the app will support voice activation. Users will be able to start voice commands by opening with “Hey Spotify”. Unfortunately, it seems the tool will only work when the app opens.

In other words, you won’t be able to access Spotify from elsewhere on a device through your voice.
It is worth noting Spotify’s music streaming rivals already have their own integrated voice commands. Pandora allows users to manage the app through voice, as does Apple Music by leveraging Siri.
If Spotify’s integration is similar, we can expect voice commands to be expansive. Some of the core commands on Pandora include more commands beyond the ability to play/pause, and skip tracks that Alexa and Google offer.
For example, users can play themed music, such as “playing songs for my workout” and utter open-ended requests, like “play something else”.

No More Cortana on Spotify
Spotify’s decision to develop its own voice assistant makes Microsoft’s decision to remove music playback functionality from Cortana a little easier to take. Or at least it would if Microsoft had not scaled back Cortana wholesale.
Earlier this week, the company announced a feature rollback, removing many consumer-focused abilities from Cortana.
“Some consumer skills including music, connected home and third-party skills will no longer be available in the updated Cortana experience in Windows 10. We’re also making some changes to where Cortana helps you. As part of our standard practice, we are ending support for Cortana in older versions of Windows that have reached their end-of-service dates.
“We recommend that customers update their devices to the latest version of Windows 10 to continue using Cortana. We’ll also be turning off the Cortana services in the Microsoft Launcher on Android by the end of April.”

Source Winbuzzer

read more
Exchange 2013

Why Exchange admins should be very worried

10-02-2020-457-Generic-Image-Generic-images-of-podcast-computers-mailbox-migrations-LOW

If you haven’t already done so, this week you should be applying patches to your Exchange Servers. A reasonably easy to exploit vulnerability has been disclosed by Microsoft as CVE-2020-0688.
Sigi and I talked about this in this week’s episode of The Practical 365 podcast, but this is important enough to write about separately in case you missed the show.
The TL:DR version of this is – anyone with the username and password for a mailbox on your Exchange Server and access to the /ecp directory can execute code as the SYSTEM account on the server itself.
The proof-of-concept exploits show this can be achieved by sending it an easily crafted URL using freely obtained open source tools.
This vulnerability is due to Microsoft using the same set of cryptographic keys on every Exchange Server installation. The keys being stored in plain text in a web.config file on every server.
The bad news is that although it has taken nearly ten years for this to be noticed, now it has, would be attackers are acting quickly. Security researchers are already seeing scans for public-facing Exchange servers to obtain build version information. If you publish OWA and ECP externally the next step by these malicious people will be to attempt to gain a set of working credentials to access Exchange. There are already tools available to use social networks like LinkedIn to harvest email addresses and of course tools to automate login attempts.
Make no mistake – if you publish Exchange externally and don’t patch, it’s only a matter of time until this is exploited.
Even if you don’t publish Exchange externally, you should consider this a threat. Not all staff follow the rules and it’s possible an insider within your organization may use this opportunity to take advantage of the rights an Exchange computer account has. The amount of damage someone could do easily shouldn’t be understated.
Simon Zuckerbraun, of the Zero Day Initiative, has produced a comprehensive write-up on their blog that provides a vast amount of detail about the vulnerability including a walk-through on how to exploit it. It makes for worrying reading – all an attacker needs is a compiled version of ysoserial.net, the validation key from either his article – or any Exchange Server– and then by crafting a URL GET request to /ecp/default.aspx they can do as they wish. If that hasn’t worried you yet, read the article now.
Getting patches for Exchange
Patches are available for all support versions of Exchange Server – from 2010 through to 2019 and all are affected.
The update comes in the form of an Update Rollup, UR30, for Exchange 2010, and security updates for the latest Cumulative Updates for Exchange 2013, 2016 and 2019. If you aren’t running the latest CUs for Exchange 2013 or higher, then you will need to get current as well as subsequently applying the patch.

Source Practical365

read more
Exchange 2016

How to inventory membership of Exchange Groups, recursively

download (1)

To this day, one of the most common questions I run into on technical communities is “how do I generate a list of all members of all groups in my organization”. Even though there are dozens of script samples and tools available on the internet for this task, it seems that they are either hard to find or not ticking all the boxes, therefore people are still trying to find a better solution. For this reason, as well as some recent advancements in the Microsoft Graph APIs, I decided that it’s worth publishing another article on this topic. Plus, it helps us keep the blog a truly practical resource.

Handling recursive output via the directory tools

One of the problems people face when inventorying group membership is making sure membership of nested groups is expanded, that is, the output should include any direct and indirect members of the group. It can go the other way too, by listing all of the groups a given user is a member of, including “parent” ones.

In the AD world, this is a relatively easy task, thanks to the so-called matching rule object identifiers and more specifically the LDAP_MATCHING_RULE_IN_CHAIN OID one. Designed to “traverse” the hierarchy, these constructs can be used to cycle over each parent (or child) object and match them against a filter. Although this type of filter only works against the object’s DistinguishedName value and the syntax can look scary, it gets the job done, and fast.

For example, if you want to list all AD groups a given user is a member of, including nested groups, you can use the first cmdlet below. The second one can be used to list all users that are a member of a given group, or any group nested under it. The third one generalizes this example to include any object types, not just users.

[ps]#List all AD groups a given user is a
member of

Get-ADGroup -LDAPFilter
“(member:1.2.840.113556.1.4.1941:=CN=vasil,CN=Users,DC=michev,DC=info)”

#List all USERS members of a given group

Get-ADUser -LDAPFilter
“(memberof:1.2.840.113556.1.4.1941:=CN=DG,CN=Users,DC=michev,DC=info)”

#List all OBJECTS that are members of a
given group

Get-ADObject -LDAPFilter
“(memberof:1.2.840.113556.1.4.1941:=CN=DG,CN=Users,DC=michev,DC=info)”[/ps]

Use of these filters is not limited to just the AD PowerShell cmdlets, in fact you can run the exact same queries via dsquery or similar tools. The AD PowerShell module does add one additional helpful method for the scenarios we examine. Namely, the –Recursive parameter for the Get-ADGroupMember cmdlet, which “flattens” out the membership list by returning only objects that don’t contain child entries. The syntax is of course much simpler compared to the filters we examined above, but on the downside, the output will only include user objects when the –Recursiveparameter is used. An example is shown below:

[ps]Get-ADGroupMember DG -Recursive[/ps]

In Office 365 and the underlying Azure AD, the methods outlined above are not available. The good news is that we just recently got support for the so-called transitive membership queries, which practically function the same. For example, the below query will return all direct and indirect members of a given group, including users, contacts, groups and so on:

[ps]https://graph.microsoft.com/beta/groups/c91cd116-a8a5-443b-9ae1-e1f0bade4a23/transitiveMembers[/ps]

This method is currently only available when querying the Graph API directly, and only when using the /beta endpoint, but hopefully, it will be exposed as a parameter for cmdlets in the Azure AD module. Unfortunately, as with the AD methods, it only covers objects which the underlying directory recognizes, meaning it’s not applicable to all group types.

Handling Exchange recipient types

Which brings us to the next common issue, the fact that most solutions out there don’t cover objects such as Office 365 Groups, Dynamic Distribution Groups, mail-enabled Public folders and so on. Some of these object types exist only in the Exchange directory, others span multiple workloads and handling them requires special treatment, and some are simply more “exotic” and usually neglected.

This in turn means that if we want a proper inventory of all recipient types recognized by Exchange, we cannot use the methods outlined above. The first logical action then is to look at the Exchange tools and use any methods exposed therein. As it’s often the case, the Get-Recipient cmdlet can offer a potential solution. Indeed, you can use the following filter to get all the valid Exchange recipients that are member of a given group:

[ps]Get-Recipient -Filter “MemberOfGroup -eq ‘CN=MESG,CN=Users,DC=michev,DC=info’”[/ps]

Unfortunately, this method does not expand the membership of any nested groups. In turn, this means that if you want to collect a comprehensive inventory of all your Exchange (Online) group objects and their members, you will have to iterate against each group, expand its membership, then rinse and repeat for any nested groups. The logic to do this in code is not very complex, and we’ve had PowerShell script samples that cover this for years. The main problem is the amount of resources consumed and the time it will take to complete the script.

With that in mind, I’ve decided to put together a script that follows some of the best practices for running against Exchange Remote PowerShell. We will utilize my preferred method of using implicit remoting and minimizing the amount of data returned by selecting just the properties we need via Invoke-Command. Using server-side filtering where possible is also a very good idea. You will find a link to the script at the end of the article, so if you aren’t interested in the details, then skip the next sections.

One additional limitation of the Get-Recipient cmdlet is that it does not return any objects of type User and ExchangeSecurityGroup, that is not mail-enabled objects which are synchronized from Azure AD. Although in general, you can just ignore these, other cmdlets such as Get-DistributionGroupMember might return them in the list of members.

Group types recognized by Exchange (Online)

When using long-running scripts, it’s always a good idea to exclude any objects you’re not interested in. With that in mind, the script attached to this article is designed to accept several parameters, designating the different types of Exchange groups for which you want to generate the membership inventory. Those include:

  • “Traditional” Distribution groups, which are included by default if you don’t specify any parameters, or use the –IncludeDGs switch
  • Mail-enabled Security groups, for which the above logic applies
  • Office 365 (or Modern) Groups, included when you specify the –IncludeOffice365Groups switch
  • Dynamic Distribution groups, included when you specify the –IncludeDynamicDGs switch
  • All of the above, which is the behavior used when you specify the –IncludeAll switch

One particular group type I have excluded are RoomLists, which in my experience people simply don’t want listed in these reports. If you do want to include them, feel free to make the relevant changes in the code (line 111, 225). If you are running the script against on-premises Exchange install, you might want to remove any references to GroupMailbox objects as well. Although the script runs just fine in Exchange 2019 EMS, I haven’t checked older versions, and not all of them will recognize these object types.

Handling Office 365 Groups

Office 365 Groups, also known as Modern Groups, are often neglected when generating membership inventory. As Office 365 Groups do not support nesting, they are relatively simple to handle. However, different cmdlet needs to be used to list their membership, namely the Get-UnifiedGroupLinks cmdlet. Here’s an example:

[ps]Get-UnifiedGroupLinks firstgroup -LinkType member[/ps]

If you specify the –IncludeOffice365Groups switch, the script will ensure that all Office 365 Groups in your organization are enumerated and their membership included in the output. In addition, the script will also include these types of objects in the output whenever it finds an Office 365 Group nested inside another group, and will expand their membership if you specify the corresponding switch parameters. But, I’ll speak more on that later.

Handling Dynamic Distribution Groups

Exchange Dynamic Distribution Groups are a special case, as they don’t have preset membership. Instead of “listing” their members, we can “preview” the current list of recipients under the scope of the DDG filter, by means of using the Get-Recipient cmdlet. Here’s an example:

[ps]Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup DDG).RecipientFilter[/ps]

While using cmdlets such as the above one isn’t anything particularly complicated, it’s not uncommon for DDGs to have filters that include the entire organization or large parts of it. As any valid Exchange recipient is included by default, sans some system objects, it’s more than likely that a DDG can have multiple other group objects “nested”, including other DDGs. And, in some cases the initial DDG can be included as a member of some of these groups. Of course, this scenario is not limited to just DDGs, it’s simply more common with them because of the membership model used.

Handling nested groups

In order to handle nested groups, we need a solution that can detect recursion and break processing as needed. To help with that, I’ve broken down the script into several smaller functions, with the “master” one trying to keep a track of whether a “child” group was already processed, or links back to the “parent”. As I am not a programmer by trade, my solution is hardly the best in terms of code practices, but it seems to do the job just fine, at least for the scenarios I could think of. If you have groups nested 10 levels deep with recurrence on every level, the script will most likely still loop indefinitely.

Assuming the code part is handled correctly, one must also decide how to handle the output. Some people will be fine just knowing that a given group has nested groups in its membership, and simply treat them as another “regular” member. Others will want to get a “flattened” list of members, with the membership of any nested groups expanded and added to the list of members of the parent group. This is the behavior when you invoke the script with the –RecursiveOutput switch. Lastly, if you want to get both the flattened membership and the email address of any nested groups, use the –RecursiveOutputListGroups switch together with the –RecursiveOutput one. Examples of the output in the different scenarios can be found in the screenshot below:

Inventorying membership of Exchange groupss

In all three examples, the script run only against a single distribution group, “DG”. The top example list just direct members of the group, the middle one includes any members of the nested “empty” group as well, since the –RecursiveOutput switch was used. Lastly, the bottom example was run with both the –RecursiveOutput and –RecursiveOutputListGroups switches, and thus includes the membership of any nested groups, as well as an entry that lists the address (or identifier) for the actual nested group.

Additional notes

Most of the building blocks of the script were explained in the previous sections, however there are few additional things to mention. First of all, the script doesn’t handle connectivity to Exchange, this part is up to you. It will invoke the Check-Connectivity helper function to detect and reuse any existing Exchange Remote PowerShell sessions, including EMS ones. Failing that, it will try to establish a session to ExO using basic auth, but that’s all. If you are connecting to any of the “sovereign” clouds or your admin credentials are protected by MFA, do the connect part manually, then invoke the script.

By default, the script will export the results to a CSV file in the current directory and will also store it in the $varGroupMembership global variable so that you can reuse it directly in the current session if you need to sort or filter it further. If you want to generate a separate CSV file for each group, uncomment line 86. Be warned though, if the script ends up in an infinite loop because of recursively nested groups, this will have quite an unpleasant impact on the filesystem!

An alternative approach might be to dot-source the script or simply reuse the function in your own scripts. If you do this, be aware that the Get-Membership function should not be called directly, as it relies on other functions for error handling and expects a properly formatted object. For the same reasons, no help is provided for the function, but I have put detailed comments around the important parts. One scenario where you will want to edit this function is when you want to use different identifier for the group member, in which case you will have to update the script block between lines 106-113.

Speaking of identifiers, all the group objects are represented by their PrimarySmtpAddress. However, as the group members wont necessarily have an email address, a different identifier might be used for them. For example, Mail Contacts or Guest Mail Users might be represented by their ExternalEmailAddress attribute instead. Among other properties that might be used as the identifier you can find UPNWindowsLiveIDExchangeGUID or ExternalDirectoryObjectId. In all cases though, the member should be represented by an unique-valued property which you can use to identify the corresponding Azure AD object, if such exists.

While I’ve tried to optimize the script as much as possible, in a large environment it will still end up issuing thousands of cmdlets and you will most likely be throttled. Adding some artificial delay to the script is a simple way to combat this, so every time the script processes a new “top level” group, 300ms delay is added as part of the connectivity check (line 21). This seems to be sufficient to properly run the script against a medium-sized tenant (10k+ objects, 800+ groups), and it resulted in no throttling during my tests. A more comprehensive solution will require you to monitor the throttling balance, as detailed for example in this article.

While large number of groups can cause issues with throttling, a different type of issue might arise if you have groups with large number of members. Since the output CSV file contains the lists of all the group members in the “Members” column, if you are opening the file with Excel you might run into the single cell size limit, which might mess up the display as well. In my tests, groups with over 1500 members (4000+ with the nested group membership flattened) caused Excel to misbehave. Your mileage will vary, but you can always rely on other text editors or even PowerShell to work with the full member list in such scenarios.

Lastly, if the script fails or doesn’t return the results you expect, you might try running it with the –Verbose switch. Or you can also drop a comment here, over at the T

read more
Exchange 2013

Exchange Best Practices: Datacenter Activation Coordination Mode

download

Datacenter Activation Coordination mode (DAC mode) is a feature of Exchange database availability groups that is designed to prevent split brain scenarios.

Within a database availability group (DAG) each database can have one active copy, and up to 15 passive copies at any given time. Changes that occur in the active database copy are replicated to the passive copies by a process of continuous replication. The active copy can be dismounted, and one of the passive copies mounted to become the active copy, when a switchover or failover occurs.

In a split brain scenario, two copies of a database would be active at the same time, mounted on DAG members that are unable to communicate with each other due to a network problem, causing the databases to diverge. This is a situation that must be avoided, because it creates a difficult recovery scenario and will likely result in data loss.

DAC mode enables a protocol called Datacenter Activation Coordination Protocol (DACP). You can read an example of how DAC mode and DACP work to avoid split brains in this article.

The recommended practice for Exchange Server DAGs is to enable DAC mode if:

  • The DAG has more than one member (DAGs start with zero members, and can have one member)
  • Third party replication mode is not enabled, or the third party replication vendor specifies that DAC mode can be used

In addition to preventing split brains, DAC mode enables the use of Exchange site-resilience cmdlets (Stop-DatabaseAvailabilityGroupRestore-DatabaseAvailabilityGroup, and Start-DatabaseAvailabilityGroup). Those cmdlets are used perform datacenter switchovers.

To review the DAC mode configuration for a DAG, use the Get-DatabaseAvailabilityGroup cmdlet.

To enable DAC mode, use the Set-DatabaseAvailabilityGroup cmdlet.

DAC mode can be enabled for DAGs that exist within a single datacenter location. A multi-site DAG is not required. Although less likely, a split brain can still occur for DAGs within a single datacenter location under the right conditions.

 
read more
Exchange 2013

Rebuilding Content Indexes for Exchange Databases

5-content-index-02

In the comments of my blog post about repairing failed content indexes, Tipza asks

How do you monitor the status of this rebuild?

To answer the question, here’s an excerpt from the Exchange Server Troubleshooting Companion.

When the content index for a database has become corrupt, it will need to be rebuilt, or reseeded from another database copy in the DAG. For now, let’s look at the process for a non-DAG Mailbox server, and demonstrate the different procedure for DAGs later in this chapter.

This process involves removing the existing content index files, which will trigger Exchange Search to re-index that database. The re-indexing process can cause a high load on the Exchange server, which may impact performance for the server. So you should carefully consider the timing of any content index rebuilds, and how it might impact your end users. The content index files are located in the same path as the database EDB file, in a sub-folder named with a GUID.

5-content-index-01

Before the corrupt index files can be removed, the Exchange Search services must be stopped. While these services are stopped, searches in OWA will not be able to be performed by end users, and all of the database content indexes on the server will be reported as “Failed” by Get-MailboxDatabaseCopyStatus.

Next, delete the GUID-named folder that contains the content index files. If the folder will not delete due to files in use, then it’s likely that either:

  • You haven’t stopped the correct search services
  • Another process, such as file-level anti-virus software, has a lock on the folder (and may be the cause of the index corrupting to begin with)

After deleting the files, start the search services again.

After a delay while Exchange Search evaluates the situation, the database will be re-indexed. The content index will have a state of “Crawling” while this is occurring.

You can monitor the progress of the database crawl by watching the MSExchange Search IndexesCrawler: Mailboxes Remaining counter in Performance Monitor for that database instance.

5-content-index-02

read more
Exchange 2013

Microsoft Warns of Potential Data Loss during Public Folder Migrations

download

Microsoft has issued a warning in KB3161916 about a potential data loss scenario that can occur during public folder migrations. Before anyone panics, it’s important to understand that this issue impacts public folders where…

…all your folders’ replicas aren’t on the primary database (the primary database server which the migration service connects to). All data which is initially present in folders that are being migrated are copied, but any incremental changes that are posted after the initial sync may be lost.

Thinking back to the public folder migrations I’ve performed in the field, they all happened to be for single-database environments. So this bug would not impact them. Similarly, for other projects where I’ve assisted in some way, the risk of data loss had been mitigated by adding replicas of all public folders to the databases on the server where the migration service was connecting.

For customers who do fall into the scenario in which this bug occurs, the risk is that any changes to data in folders that are held in replicas away from the primary server, or any new folders that are created on those replicas, will not be included in the incremental synchronization pass that is performed to complete the public folder migration. Microsoft explains the scenario in more detail here.

The fix for this issue is expected to arrive in Exchange 2013 CU13 and Exchange 2016 CU2, as well as be rolled out to Exchange Online in a similar timeframe. In the meantime, if you can’t add replicas of all of your public folders to the server that the migration service connects to, Microsoft recommends you wait for the fix before completing your public folder migration.

read more
Exchange 2013

Server Component States During Cumulative Update Installation

download

If you’ve performed maintenance on a database availability group member before, then you’re likely already familiar with the procedures for putting DAG members in and out of maintenance mode. If this is a new topic for you, here’s two articles describing how it’s done:

During that process, you set the ServerWideOffline component to an Inactivestate, using the requester of “Maintenance”. At the end of your CU install, you set the ServerWideOffline component back to an Active state, again specifying the requester of “Maintenance”.

There are multiple requesters that can be used to mark components active and inactive. We use “Maintenance” when we are doing maintenance, and there are others as well: Functional, HealthApi, Sidelined, and Deployment. If any one of the requesters has a server component marked as inactive, then the component will remain inactive.

Where this can trip you up is during maintenance, in particular two scenarios. First, let’s take a look at the ServerWideOffline component state of a healthy DAG member.

Now here’s the first problem scenario. Let’s say you start the setup process for a cumulative update in GUI mode, and step through the first few dialogs, but don’t actually start the upgrade. For some reason you decide to cancel and do the upgrade at another time. Later, you discover your Exchange server is not working correctly. Why? Because Exchange setup has set ServerWideOffline to an Inactive state, using the requester “Functional”. It does this surprisingly early in the process too, so beware.

The other scenario is an upgrade that is interrupted by a server issue. This one is rare, but I’ve seen it enough times that it’s worth mentioning. Let’s say a cumulative update is running, and at a key moment in the process the server crashes and restarts. The administrators take a look, and as far as they can see the upgrade has worked. Perhaps they check the server version number using Get-ExchangeServer, or check the Exchange services on the server are all installed and running. They complete their maintenance steps by running Set-ServerComponentState to set ServerWideOffline back to an Active state, using their requester of “Maintenance”. And then again, a short time later, they discover the server is not working correctly. Why? Same issue as above, the ServerWideOfflinecomponent is inactive, due to Exchange setup marking it so with the requester “Functional”.

In both cases the solution is the same. Run Set-ServerComponentState and use the requester “Functional” to set ServerWideOffline back to an Activestate.

In the case of the interrupted upgrade, you should also give the server a thorough health check and consider re-running the CU to get a clean result.

 
read more
Exchange 2013

Using Activation Policies to Prevent Database Copies Mounting in Other Sites

exchange-2016-migration-end

A lot of organizations that deploy multi-site database availability groups do so with the intention of using one site for normal production operations, and one for disaster recovery. This design usually leads to a desire to control where database copies can automatically activate, or failover to, when there is a problem with the active copy.

Consider a scenario in which four DAG members have been deployed, with two in the primary site and two in the disaster recovery site. I’ve illustrated a single database with four copies, but in reality there could be several more databases as well. Only one database is required to demonstrate this scenario though, so let’s keep it simple. By default, the database DB01 can failover to any of the available DAG members automatically, including the DR site.

exchange-dag-activation-policies-0

If that is not desirable for the organization, then activation policies on the mailbox servers are commonly used to block automatic activation of the database copies in the DR site.

This doesn’t prevent manual activation of course, so administrators can still make their own decision to “fail over to DR” when necessary.

exchange-dag-activation-policies-1

The problem with the configuration above is that it greatly reduces the number of available database copies for automatic recovery of service in the event of a failure. If DB01 is active on PR-EXCH01 and needs to fail over, and PR-EXCH02 happens to be unhealthy for some reason or is down for planned maintenance, then there’s nowhere for the database to fail over to, and it will go offline instead. Furthermore, even if you do manually switchover to DR-EXCH02 for example, the database is still blocked from failing over to DR-EXCH02 if a second issue arises.

To combat that, some organizations set the DR site to use activation policies of IntrasiteOnly.

That solves one of the two problems, but is still not ideal, in my opinion.

exchange-dag-activation-policies-2

If you’re willing to accept database failing over to the DR site when necessary to maintain service availability, but you prefer the databases be active in the primary site, then you can leave the activation policies set to Unrestricted and set the DatabaseCopyActivationDisabledAndMoveNowproperty to $true instead. This allows databases to fail over, but they will automatically move back to a healthy database copy on a healthy server that has DatabaseCopyActivationDisabledAndMoveNow set to $false (and is also configured with an activation policy of Unrestricted) when one becomes available, usually within a few minutes.

exchange-dag-activation-policies-3

 
read more
1 2 3 5
Page 1 of 5