When we migrated to Exchange 2013, we only set up one Public Folder Mailbox, since our Public Folders weren't heavily used. Soon, we started getting SCOM alerts that there were too many connection attempts to the single PF Mailbox.
After creating a new PF mailbox and attempting to move some of the Public Folders over, I kept getting the following error:
Destination Folder Hierarchy Inconsistent Transient Exception has occurred
Luckily the fix was pretty simple, just restart the Mailbox Replication Service (MRS) which controls mailbox moves.
**Note** You'll need to restart the MRS on all of your servers.
That being said; I'm not sure what causes this issue, especially since we're on RU11...you'd think MS would fix this by now.
Saturday, December 26, 2015
Wednesday, December 16, 2015
Exchange Dynamic Distribution Group Members Report Script
One of the most common requests I get from users is: "Who is in this Query-based Distribution Group?"
Most often the users who should be in the group aren't receiving messages as they should. So I wrote a quick script that pulls the members of a Dynamic Distribution Group and generates a nicely formatted HTML report that the user can easily read.
Grab the script from my Google Drive here
To run the script, fire up the Exchange Management Shell (EMS).
Change to the directory where you saved the script by running:
cd C:\Scripts
**Note** Change C:\Scripts to reflect your directory
Then, run:
Get-DynamicGroupMembers.ps1
The Script will prompt you to enter a Distro Group name
**Note** You do not need quotes around the name
Next, it will prompt you to provide a file name, such as DDLReport.htm
**Note** You will need to specify .htm to the file name.
The script will then generate the report and save the HTML file in the location of the .ps1 file eg. C:\Scripts
Now you'll have a nice and pretty report to hand off to the user.
Most often the users who should be in the group aren't receiving messages as they should. So I wrote a quick script that pulls the members of a Dynamic Distribution Group and generates a nicely formatted HTML report that the user can easily read.
Grab the script from my Google Drive here
To run the script, fire up the Exchange Management Shell (EMS).
Change to the directory where you saved the script by running:
cd C:\Scripts
**Note** Change C:\Scripts to reflect your directory
Then, run:
Get-DynamicGroupMembers.ps1
The Script will prompt you to enter a Distro Group name
**Note** You do not need quotes around the name
Next, it will prompt you to provide a file name, such as DDLReport.htm
**Note** You will need to specify .htm to the file name.
The script will then generate the report and save the HTML file in the location of the .ps1 file eg. C:\Scripts
Now you'll have a nice and pretty report to hand off to the user.
Wednesday, December 2, 2015
Exchange 2013 Hide MailContacts From The GAL
Back in Exchange 2010 you could use the Exchange Management Console (EMC) to hide any type of recipient from the GAL.
Unfortunately for admins who only use the Exchange Admin Console (EAC) you can't do that anymore in Exchange 2013; you have to use the Exchange Management Shell (EMS).
You can still hide MailUsers in the EAC, but not Contacts, which is strange. Yes I'm talking to you, Microsoft...
Luckily, it's a simple cmdlet to hide Contacts.
Fire up the EMS, and run:
Set-MailContact "alias" -HiddenFromAddressListsEnabled $true
**Note** Change "alias" to the MailContact name you're working with.
Now, that contact is hidden and you can check with this cmdlet:
Get-MailContact "alias" | fl *hidden*
**Note** Again, change"alias"
Unfortunately for admins who only use the Exchange Admin Console (EAC) you can't do that anymore in Exchange 2013; you have to use the Exchange Management Shell (EMS).
You can still hide MailUsers in the EAC, but not Contacts, which is strange. Yes I'm talking to you, Microsoft...
Luckily, it's a simple cmdlet to hide Contacts.
Fire up the EMS, and run:
Set-MailContact "alias" -HiddenFromAddressListsEnabled $true
**Note** Change "alias" to the MailContact name you're working with.
Now, that contact is hidden and you can check with this cmdlet:
Get-MailContact "alias" | fl *hidden*
**Note** Again, change"alias"
Exchange 2013 DAG Heartbeat Threshold on VMWare
Over the past couple weeks we'd been noticing quite a few DAG failovers and cluster service stoppages in our Exchange 2013 environment. Our multi-role servers are hosted on VMWare and we noticed some vMotion events happening. Technically vMotion shouldn't cause any disruption in Exchange, but ours were migrating a couple times within a few minutes...yeah our infrastructure team needs to fix that.
It's best practice to bump up the DAG heartbeat interval (per VMWare) to allow for host migrations.
To change the interval values on the cluster service, you'll need to use Windows PowerShell.
**Note** It's totally safe to make the change during production hours, as it's transparent and does not require service restarts.
To get the default values, fire up Windows PowerShell and run:
Get-Cluster | fl *subnet*
It will return a list like so:
CrossSubnetDelay : 1000
CrossSubnetThreshold : 5
PlumbAllCrossSubnetRoutes : 0
SameSubnetDelay : 1000
SameSubnetThreshold : 5
The "1000" value is the milliseconds between heartbeats (1 second) and the "5" is the amount of heartbeats.
You'll want to be safe and only change the SameSubnetDelay interval to 2 seconds (2000 milliseconds), which according to VMWare is plenty of time for the cluster to adjust for any vMotion.
To change the interval, run the following:
(Get-Cluster).samesubnetdelay = 2000
Now, run the original cmdlet again and you'll see your changes:
Get-Cluster | fl *subnet*
CrossSubnetDelay : 1000
CrossSubnetThreshold : 5
PlumbAllCrossSubnetRoutes : 0
SameSubnetDelay : 2000
SameSubnetThreshold : 5
**Note** You only need to do this on one of the DAG nodes, as the changes will replicate across the cluster.
Now you'll have less failovers during vMotion migrations.
It's best practice to bump up the DAG heartbeat interval (per VMWare) to allow for host migrations.
To change the interval values on the cluster service, you'll need to use Windows PowerShell.
**Note** It's totally safe to make the change during production hours, as it's transparent and does not require service restarts.
To get the default values, fire up Windows PowerShell and run:
Get-Cluster | fl *subnet*
It will return a list like so:
CrossSubnetDelay : 1000
CrossSubnetThreshold : 5
PlumbAllCrossSubnetRoutes : 0
SameSubnetDelay : 1000
SameSubnetThreshold : 5
The "1000" value is the milliseconds between heartbeats (1 second) and the "5" is the amount of heartbeats.
You'll want to be safe and only change the SameSubnetDelay interval to 2 seconds (2000 milliseconds), which according to VMWare is plenty of time for the cluster to adjust for any vMotion.
To change the interval, run the following:
(Get-Cluster).samesubnetdelay = 2000
Now, run the original cmdlet again and you'll see your changes:
Get-Cluster | fl *subnet*
CrossSubnetDelay : 1000
CrossSubnetThreshold : 5
PlumbAllCrossSubnetRoutes : 0
SameSubnetDelay : 2000
SameSubnetThreshold : 5
**Note** You only need to do this on one of the DAG nodes, as the changes will replicate across the cluster.
Now you'll have less failovers during vMotion migrations.
Saturday, November 21, 2015
Exchange Error: 451 5.7.3 Cannot achieve Exchange Server authentication
While planning to decommission our old Exchange 2010 environment we had to change the CAS/Hub Transport IPs because we needed to reuse them for some of our new SMTP relays - we have quite a few (way too many) relaying servers that use IP instead of SMTP hostname.
After changing the IPs, the Transport Queues filled up with the following error:
451 4.4.0 Primary target IP address responded with: "451 5.7.3 Cannot achieve Exchange Server authentication." Attempted failover to alternate host , but that did not succeed. Either there are no alternative hosts, or delivery failed to all alternative hosts.
This affected all internal mail, because the Exchange 2010 servers are still routing to our 2013 environment.
The problem was easily overlooked, but the fix was simple as well:
On your new environment (the servers you are sending to) check your relay connectors and make sure they do not include the IP address or subnet of your old environment (the servers you're sending from).
You might have to restart the Transport Service on the old servers, but the queues should now start emptying out.
After changing the IPs, the Transport Queues filled up with the following error:
451 4.4.0 Primary target IP address responded with: "451 5.7.3 Cannot achieve Exchange Server authentication." Attempted failover to alternate host , but that did not succeed. Either there are no alternative hosts, or delivery failed to all alternative hosts.
This affected all internal mail, because the Exchange 2010 servers are still routing to our 2013 environment.
The problem was easily overlooked, but the fix was simple as well:
On your new environment (the servers you are sending to) check your relay connectors and make sure they do not include the IP address or subnet of your old environment (the servers you're sending from).
You might have to restart the Transport Service on the old servers, but the queues should now start emptying out.
Tuesday, October 27, 2015
Exchange Migration Intel Gathering Tools
I've been meaning to write this post for some time...stuff just gets in the way :)
When performing Exchange migrations, I use several tools (Exchange scripts, cmdlets, apps) that help me gather information about the source environment. I've included a .zip folder with all said tools, and I'll go over what goodies are included.
Disclaimer: A bunch of the scripts and apps are not my own; I have just found them on the web. That being said, I need to give a giant thanks to the Exchange Wizards that created these!
**Note** You will need Admin Access to the source AD/Exchange environment in order to run these tools...but you have that already, right?
The Apps:
AD Topology Diagrammer
Microsoft
The Topology Diagrammer can read your Exchange environment and spit out a very in-depth overview to a Visio diagram.
**Note** You will need Visio Viewer in order to view the diagrams and Visio 2003 or newer if you want to edit the drawings.
Just fire it up, select the Exchange tab, pick the info you need to draw and hit Discover:
The Exchange Management Shell Scripts:
DistributionGroupMemberReport
Satheshwaran Manoharan
Reports on Distro Group Members and outputs them to a CSV file. Useful when you need to migrate groups and keep members intact.
Get-Dist-Group-Stats
Reports the message count sent to Distro Groups within a date range. Useful to see exactly how many groups are actually being used...you've seen those environment with thousands of groups, and maybe 50 are being used.
**Note** You'll want to edit the date range in the script.
Get-EASDeviceReport
Paul Cunningham
Produces a report of ActiveSync device associations in the organization. Useful to gauge the ActiveSync load on the environment.
Get-ExchangeEnvironmentReport
Paul Cunningham
Generates a very in-depth report of the current state of the Exchange environment, including Servers and Versions, Database list and sizes, Mailbox Count, and a ton of other info.
GetMessageStatsToFile
Justin Beeden
Checks Message Tracking Logs and pulls message statistics for an Exchange Organization, and lets you specify how many days to go back and then outputs to a CSV. It also pulls distro list stats as well.
GetPublicFolderReport
Steve Halligan
Pulls a report of Public Folders with Paths, Item Count, Sizes, Access Times and more.
Test-ExchangeServerHealth
Paul Cunningham
Performs a health check on Exchange servers as well as DAGs and outputs to an HTML report, or you can optionally email the report.
GetAllExchangeServers
Monimoy Sanyal
A VBScript to get a list of all Exchange Servers with versions.
The Shell cmdlets:
Check Build and Rollup Number
Useful to check if the Servers in the source environment are up to the proper patch level, especially if you're going to run co-existence.
Check Database Backup Status
Useful to check if the environment is currently backed up...you don't wanna lose anything.
Get Distribution Groups With No Members
Check which groups have no members - you can then decide to delete those, because they're obviously not be used.
Get Mailbox Quotas Not Set to Default
Check which mailboxes aren't set to the default quotas set on the Database. Useful if you need to keep those limits when migrating, and for storage space planning in your target organization.
Get Mailboxes With Forwarding Set
List mailboxes that are forwarding to another address. This is useful, since those will likely need to keep forwarding after the move.
Get Top 100 Largest Mailboxes
List the top 100 "I don't delete anything and email is my personal repository" offenders and tell them to empty their junk or archive before you move their mailbox!
The Folder:
All the above is included in a .zip folder that I have shared out on my Google Drive.
The apps are zipped within the folder, the scripts are .ps1 files, and the cmdlets are .txt files.
You can grab the Exchange Migration Intel Gathering Folder from here.
If you have any more tools that you use for migrations, leave me comment and I'll add them to the list and folder!
Happy migrating :)
When performing Exchange migrations, I use several tools (Exchange scripts, cmdlets, apps) that help me gather information about the source environment. I've included a .zip folder with all said tools, and I'll go over what goodies are included.
Disclaimer: A bunch of the scripts and apps are not my own; I have just found them on the web. That being said, I need to give a giant thanks to the Exchange Wizards that created these!
**Note** You will need Admin Access to the source AD/Exchange environment in order to run these tools...but you have that already, right?
The Apps:
AD Topology Diagrammer
Microsoft
The Topology Diagrammer can read your Exchange environment and spit out a very in-depth overview to a Visio diagram.
**Note** You will need Visio Viewer in order to view the diagrams and Visio 2003 or newer if you want to edit the drawings.
Just fire it up, select the Exchange tab, pick the info you need to draw and hit Discover:
Exchange Server Mailbox Statistics Tool
The Mailbox Statistics Tool is a GUI tool that can be run against one, several, or all mailboxes on an Exchange server. It then spits out nicely formatted HTML reports. It can also email those reports, if you need to send them up to management for review.
Just select your Domain Controller, Exchange Server, Database, and Mailbox(es) and fire off the report:
DistributionGroupMemberReport
Satheshwaran Manoharan
Reports on Distro Group Members and outputs them to a CSV file. Useful when you need to migrate groups and keep members intact.
Get-Dist-Group-Stats
Reports the message count sent to Distro Groups within a date range. Useful to see exactly how many groups are actually being used...you've seen those environment with thousands of groups, and maybe 50 are being used.
**Note** You'll want to edit the date range in the script.
Get-EASDeviceReport
Paul Cunningham
Produces a report of ActiveSync device associations in the organization. Useful to gauge the ActiveSync load on the environment.
Get-ExchangeEnvironmentReport
Paul Cunningham
Generates a very in-depth report of the current state of the Exchange environment, including Servers and Versions, Database list and sizes, Mailbox Count, and a ton of other info.
GetMessageStatsToFile
Justin Beeden
Checks Message Tracking Logs and pulls message statistics for an Exchange Organization, and lets you specify how many days to go back and then outputs to a CSV. It also pulls distro list stats as well.
GetPublicFolderReport
Steve Halligan
Pulls a report of Public Folders with Paths, Item Count, Sizes, Access Times and more.
Test-ExchangeServerHealth
Paul Cunningham
Performs a health check on Exchange servers as well as DAGs and outputs to an HTML report, or you can optionally email the report.
GetAllExchangeServers
Monimoy Sanyal
A VBScript to get a list of all Exchange Servers with versions.
The Shell cmdlets:
Check Build and Rollup Number
Useful to check if the Servers in the source environment are up to the proper patch level, especially if you're going to run co-existence.
Check Database Backup Status
Useful to check if the environment is currently backed up...you don't wanna lose anything.
Get Distribution Groups With No Members
Check which groups have no members - you can then decide to delete those, because they're obviously not be used.
Get Mailbox Quotas Not Set to Default
Check which mailboxes aren't set to the default quotas set on the Database. Useful if you need to keep those limits when migrating, and for storage space planning in your target organization.
Get Mailboxes With Forwarding Set
List mailboxes that are forwarding to another address. This is useful, since those will likely need to keep forwarding after the move.
Get Top 100 Largest Mailboxes
List the top 100 "I don't delete anything and email is my personal repository" offenders and tell them to empty their junk or archive before you move their mailbox!
The Folder:
All the above is included in a .zip folder that I have shared out on my Google Drive.
The apps are zipped within the folder, the scripts are .ps1 files, and the cmdlets are .txt files.
You can grab the Exchange Migration Intel Gathering Folder from here.
If you have any more tools that you use for migrations, leave me comment and I'll add them to the list and folder!
Happy migrating :)
Monday, October 19, 2015
Lepide Migrator for Exchange Review
Performing an Exchange migration is always a daunting task for a Messaging Admin, especially when it involves cross-forest moves, or even worse "cut-over" migrations.
I've done several migrations, some were easy, and some were not very fun at all. Depending on who I was working for, some organizations had migration tools to ease the process, and Lepide Exchange Migrator has always been my favorite.
It provides a Pre-Migration Analyzer, which will tell you how long a migration will take by calculating network speed, number and size of mailboxes, and bunch of other factors.
It has a Reporting feature that tracks migration history and plans for future migrations and notifies you with email alerts for the job status, job completion, or job cancelation.
It provides the option to migrate the account with SID History and current passwords from the source to target account, which is very useful in cross-forest migrations.
It provides option to migrate Public Folders and also carry over settings like mailbox Access Rights, Send As Permission, Public Folder Permissions, Send on Behalf, and Delivery Restrictions.
And what I think is the most important/useful features, is that it will map the user's Outlook Profile to their new mailbox in the target organization. This is very helpful, since a lot of the work involved in a migration is dealing with fixing Outlook issues.
Product Review:
The Migrator itself is very easy to install. It can run on pretty much everything from Windows XP to Server 2012 R2.
You can install it in either the Source or Target domain.
You will need a two-way trust between the two environments and it does require Outlook (32-bit or 64-bit) to be installed on the machine. The most involved part of the process is setting up DNS forwarding and the trust(s) but you'll have to do that for a co-existence migration anyway.
After the installation, now comes the fun and easy part - the migration.
Lepide couldn't have made it easier to migrate Exchange.
In a broad overview: you create a migration project, connect to the other organization, select the users to migrate (or import a CSV with a list of users) set your filter of what to include in the move, map the mailboxes, create your notifications and schedule and let 'er rip.
When we cut-over users, the most time-consuming part is re-doing Outlook profiles. By using the Migrator, after the successful mailbox migration, you can use the Profile Manager to replace the old Outlook profiles of the source with new Outlook profiles of the target (according to the mapping performed at the time of Job creation). You can choose to replace all the Outlook profiles or only the default profile. Also, you can create a new profile when no Outlook profile is found. This make it so easy, instead of manually updating or re-creating the profile with the new Exchange account.
Moving Public Folders is super easy as well. You can sync them back and forth between environments and (unlike native migrations) it doesn't duplicate items.
There were two drawbacks to the product:
Having to create a two-way trust can sometimes break things in your AD structure depending on configuration (we actually had this happen when one of our teams created a trust). I would be nice if there was a way around having to create the trust.
Outlook 2016 is not supported yet. Hopefully the Lepide devs will work that into an update soon, since Outlook 2016 will become mainstream and I'm sure most Exchange admins are testing it now.
Overall, using the Lepide Exchange Migrator makes Exchange migrations from end-to-end a breeze and I don't ever want to migrate without it! :)
I've done several migrations, some were easy, and some were not very fun at all. Depending on who I was working for, some organizations had migration tools to ease the process, and Lepide Exchange Migrator has always been my favorite.
In my current gig we go through a lot of acquisitions, where the users we bring into our organization are cut-over; meaning we create new user accounts and mailboxes in our domain, and then either archive their old mail or if they keep a tidy mailbox, we'll move their content into their new mailbox. The problem with this is, it's always difficult to map their Outlook profiles to their new mailbox, so that involves a ton of busy work.
In this post, I'll go over what the Leipde Exchange Migrator can do to help you with your migrations, and my thoughts on the product.
**Note** For now, this is just an overview. In a future post, I'll go over how to install and use the Migrator.
Notice: This is an unpaid posting. I was however provided with the full licensed software.
Notice: This is an unpaid posting. I was however provided with the full licensed software.
Product Features:
Migrate to and fro:
- Exchange 2003/2007 and Exchange 2010
- Exchange 2003/2007 and Exchange 2013
- Exchange 2010 and Exchange 2013
- Migration from any Exchange Server to Office 365
- Public Folder Migration
- Intra-forest Exchange Migration
- Cross-forest Exchange Migration
You can sync the complete source mailbox to the target environment in advance and do an incremental sync before the final cut-over. This helps in avoiding data loss and outage to the users.
It provides a Pre-Migration Analyzer, which will tell you how long a migration will take by calculating network speed, number and size of mailboxes, and bunch of other factors.
It has a Reporting feature that tracks migration history and plans for future migrations and notifies you with email alerts for the job status, job completion, or job cancelation.
It provides the option to migrate the account with SID History and current passwords from the source to target account, which is very useful in cross-forest migrations.
It provides option to migrate Public Folders and also carry over settings like mailbox Access Rights, Send As Permission, Public Folder Permissions, Send on Behalf, and Delivery Restrictions.
And what I think is the most important/useful features, is that it will map the user's Outlook Profile to their new mailbox in the target organization. This is very helpful, since a lot of the work involved in a migration is dealing with fixing Outlook issues.
Product Review:
The Migrator itself is very easy to install. It can run on pretty much everything from Windows XP to Server 2012 R2.
You can install it in either the Source or Target domain.
You will need a two-way trust between the two environments and it does require Outlook (32-bit or 64-bit) to be installed on the machine. The most involved part of the process is setting up DNS forwarding and the trust(s) but you'll have to do that for a co-existence migration anyway.
After the installation, now comes the fun and easy part - the migration.
Lepide couldn't have made it easier to migrate Exchange.
In a broad overview: you create a migration project, connect to the other organization, select the users to migrate (or import a CSV with a list of users) set your filter of what to include in the move, map the mailboxes, create your notifications and schedule and let 'er rip.
As I mentioned above; the best feature of Lepide Exchange Migrator, is the ability to map user Outlook Profiles to the new/target environment.
When we cut-over users, the most time-consuming part is re-doing Outlook profiles. By using the Migrator, after the successful mailbox migration, you can use the Profile Manager to replace the old Outlook profiles of the source with new Outlook profiles of the target (according to the mapping performed at the time of Job creation). You can choose to replace all the Outlook profiles or only the default profile. Also, you can create a new profile when no Outlook profile is found. This make it so easy, instead of manually updating or re-creating the profile with the new Exchange account.
Moving Public Folders is super easy as well. You can sync them back and forth between environments and (unlike native migrations) it doesn't duplicate items.
There were two drawbacks to the product:
Having to create a two-way trust can sometimes break things in your AD structure depending on configuration (we actually had this happen when one of our teams created a trust). I would be nice if there was a way around having to create the trust.
Outlook 2016 is not supported yet. Hopefully the Lepide devs will work that into an update soon, since Outlook 2016 will become mainstream and I'm sure most Exchange admins are testing it now.
Overall, using the Lepide Exchange Migrator makes Exchange migrations from end-to-end a breeze and I don't ever want to migrate without it! :)
Thursday, October 8, 2015
Exchange 2010 Decommission Error: "Please specify an existing server role to uninstall"
I've seen this problem on some message boards and even come across it myself when in a hurry and not paying attention.
You go to try to uninstall Exchange 2010 and you get an error saying:
"Some controls aren't valid - Please specify an existing server role(s) to uninstall"
The problem is: you have to Uncheck the Roles you want to uninstall. (If you read the line under Server Role Selection, it says to clear roles you want to remove).
I know that might seem backwards since by human nature you'd likely want to actually check things you'd want to uninstall, and MS should've written a separate uninstaller for Exchange, but...
Once you uncheck the role, hit Next and the installer will go to the Pre-req checks as normal.
You go to try to uninstall Exchange 2010 and you get an error saying:
"Some controls aren't valid - Please specify an existing server role(s) to uninstall"
The problem is: you have to Uncheck the Roles you want to uninstall. (If you read the line under Server Role Selection, it says to clear roles you want to remove).
I know that might seem backwards since by human nature you'd likely want to actually check things you'd want to uninstall, and MS should've written a separate uninstaller for Exchange, but...
Once you uncheck the role, hit Next and the installer will go to the Pre-req checks as normal.
Tuesday, September 29, 2015
Exchange 2013 Error: "Exception: Active Directory property 'homeMDB' is not writeable..."
Following up my previous post on mailbox move failures resulting in Event ID 2937 errors, I now got an error on the Exchange 2013 side with the following:
MSExchange Migration Event ID 2002
RemotePermanentException:Active Directory property 'homeMDB' is not writeable on recipient 'exchangeitup.com/Inactive Accounts/OldUser'
This fix, like the last one is easy:
Fire up ADUC (Active Directory Users and Computers).
Navigate to the OU where the account in question is located.
Right-click the account and select Properties.
Select the Security Tab.
Hit the Advanced button.
And click the Enable inheritance button.
Click OK all the way out and now move the mailbox.
MSExchange Migration Event ID 2002
RemotePermanentException:Active Directory property 'homeMDB' is not writeable on recipient 'exchangeitup.com/Inactive Accounts/OldUser'
This fix, like the last one is easy:
Fire up ADUC (Active Directory Users and Computers).
Navigate to the OU where the account in question is located.
Right-click the account and select Properties.
Select the Security Tab.
Hit the Advanced button.
And click the Enable inheritance button.
Click OK all the way out and now move the mailbox.
Exchange 2010 Error: "Property [PreviousDatabase] is pointing to the Deleted Objects container"
I recently came across the following error when trying to move a mailbox from Exchange 2010 to Exchange 2013:
MSExchange ADAccess Event ID 2937
Process mmc.exe (PID=3300). Object [CN=OldUser,OU=Inactive Accounts,DC=exchangeitup,DC=com]. Property [PreviousDatabase] is set to value [exchangeitup.com/Configuration/Deleted Objects/DB10 DEL:c664f6ea-77ae-44ff-b8c8-2e26bc49a5f7], it is pointing to the Deleted Objects container in Active Directory. This property should be fixed as soon as possible.
The problem occurred when the mailbox was last moved, and the msExchPreviousHomeMDB attribute on the account was populated with the Database it was moved from.
The fix is simple:
In Active Directory Users and Computers (ADUC), go to View, and select Advanced Features.
Go to the OU that the user is located in, right-click the account, and select Properties.
Click the Attribute Editor Tab, and double-click msExchPreviousHomeMDB.
Click the Clear button.
Now try to move the mailbox.
I still had problems moving the mailbox, but this time on the Exchange 2013 side.
I was now getting the following error:
RemotePermanentException: Active Directory property 'homeMDB' is not writeable on recipient 'exchangeitup.com/Inactive Accounts/OldUser'
Follow this post to fix the issue.
MSExchange ADAccess Event ID 2937
Process mmc.exe (PID=3300). Object [CN=OldUser,OU=Inactive Accounts,DC=exchangeitup,DC=com]. Property [PreviousDatabase] is set to value [exchangeitup.com/Configuration/Deleted Objects/DB10 DEL:c664f6ea-77ae-44ff-b8c8-2e26bc49a5f7], it is pointing to the Deleted Objects container in Active Directory. This property should be fixed as soon as possible.
The problem occurred when the mailbox was last moved, and the msExchPreviousHomeMDB attribute on the account was populated with the Database it was moved from.
The fix is simple:
In Active Directory Users and Computers (ADUC), go to View, and select Advanced Features.
Go to the OU that the user is located in, right-click the account, and select Properties.
Click the Attribute Editor Tab, and double-click msExchPreviousHomeMDB.
Click the Clear button.
Now try to move the mailbox.
I still had problems moving the mailbox, but this time on the Exchange 2013 side.
I was now getting the following error:
RemotePermanentException: Active Directory property 'homeMDB' is not writeable on recipient 'exchangeitup.com/Inactive Accounts/OldUser'
Follow this post to fix the issue.
Wednesday, September 23, 2015
Duplicate Messages in Outlook Due to Inbox Rules
I've come across the problem of duplicate email messages in Outlook quite often, and it's almost always an Inbox Rule that the user has set (and often forgot about).
With a simple PowerShell one-liner, you can check for such rules and inform the user to disable/delete them, or disable/remove them yourself.
Fire up the EMS (Exchange Management Shell) and run:
Get-InboxRule -Mailbox "user1" |fl
**Note** Change "user1" to the mailbox of the user your checking on.
You'll get an output similar to this:
RunspaceId : 53c685d4-326c-4438-b5a0-aa490c4b3762
Description : Take the following actions:
redirect the message to 'user1@exchangeitup.com'
and stop processing more rules on this message
Enabled : True
Identity : Forward Messages to Alias
InError : False
Name : [Apply to all messages]
Priority : 1
RuleIdentity : 5675183204786702859
You can see that the Rule redirects all messages to an alias; which if that alias exists in Exchange will double up messages.
To disable the Rule without intervention from the user, run:
Disable-InboxRule -Identity "Forward Messages to Alias" -Mailbox user1@exchangeitup.com
**Note Change -Identity to the rule name you're disabling and -Mailbox to the user your working with.
It's probably better to disable the rule rather than remove it, but just in case you want to do that, run:
Remove-InboxRule -Mailbox user1@exchangeitup.com -Identity "Forward Messages to Alias"
To remove all Rules from the mailbox, run:
Get-InboxRule -Mailbox "user1@exchangeitup.com " | Remove-InboxRule
That's it; have the user test and verify that there are no more dupe's.
With a simple PowerShell one-liner, you can check for such rules and inform the user to disable/delete them, or disable/remove them yourself.
Fire up the EMS (Exchange Management Shell) and run:
Get-InboxRule -Mailbox "user1" |fl
**Note** Change "user1" to the mailbox of the user your checking on.
You'll get an output similar to this:
RunspaceId : 53c685d4-326c-4438-b5a0-aa490c4b3762
Description : Take the following actions:
redirect the message to 'user1@exchangeitup.com'
and stop processing more rules on this message
Enabled : True
Identity : Forward Messages to Alias
InError : False
Name : [Apply to all messages]
Priority : 1
RuleIdentity : 5675183204786702859
You can see that the Rule redirects all messages to an alias; which if that alias exists in Exchange will double up messages.
To disable the Rule without intervention from the user, run:
Disable-InboxRule -Identity "Forward Messages to Alias" -Mailbox user1@exchangeitup.com
**Note Change -Identity to the rule name you're disabling and -Mailbox to the user your working with.
It's probably better to disable the rule rather than remove it, but just in case you want to do that, run:
Remove-InboxRule -Mailbox user1@exchangeitup.com -Identity "Forward Messages to Alias"
To remove all Rules from the mailbox, run:
Get-InboxRule -Mailbox "user1@exchangeitup.com " | Remove-InboxRule
That's it; have the user test and verify that there are no more dupe's.
Thursday, September 10, 2015
Exchange 2013 Installing Cumulative Updates
Installing Cumulative Updates (CU's) to Exchange 2013 isn't too different from Rollups (RU's) on Exchange 2010. There are some nice cmdlets built into Exchange to help ease the install, and there are some scripts floating around on the web to automate the process (I prefer to use the commands, since I have them saved and just copy/pasta into the EMS).
At the time of this post, CU9 is the latest release and it brings back some much needed features like the ability to keep Sent Items in Shared Mailboxes...why MS took that away I dunno :(
Installing Exchange 2013 CU's:
First, in your monitoring service, put the servers into Maintenance Mode, and stop backup services.
Domain Prep:
Exchange CU's usually contain schema changes, and it's best to run those commands separately, well before you install the CU to give your environment time to replicate changes. And in the case of CU9, it doesn't run ADPrep in the install...stupid.
In an elevated CMD prompt on either a Domain Controller or on one of the Exchange servers, run the following commands:
cd to C:\CU
**Note** Change "C:\CU" to where you extracted the CU setup files.
Setup.exe /prepareSchema /IAcceptExchangeServerLicenseTerms
Setup.exe /prepareAD /IAcceptExchangeServerLicenseTerms
Setup.exe /prepareDomain /IAcceptExchangeServerLicenseTerms
After the commands finish, to check that everything is complete and clean, run:
repadmin /showrepl
CU Installation:
Multirole DAG Members:
I'll be going over how to update multi-role servers that are part of a DAG on hardware load balancers, since that's the most common setup.
First, remove one server from rotation in the load balancer, which will gracefully move connections to another server and not disrupt clients.
I'm using Kemp load balancers so it'll look like this:
Fire up the Exchange Management Shell (EMS) and run the following commands separately:
$Computer = $ENV:ComputerName
Set-ServerComponentState $Computer -Component HubTransport -State Draining -Requester Maintenance
Redirect-Message -Server $Computer -Target odc-exc-mbx-c01.harriscomputer.com
Suspend-ClusterNode $Computer
Set-MailboxServer $Computer -DatabaseCopyActivationDisabledAndMoveNow $True
Set-MailboxServer $Computer -DatabaseCopyAutoActivationPolicy Blocked
Set-ServerComponentState $Computer -Component ServerWideOffline -State Inactive -Requester Maintenance
After the updates install and you bounce the server, you'll need to uninstall any extra Language Packs in CMD:
cd C:\CU
setup.exe /RemoveUMLanguagePack:fr-CA
**Note** Change "fr-CA" to the pack you have installed.
Next, make sure that the EMS is closed, or else it will throw PowerShell errors! install the CU either by browsing to the extracted files and running setup.exe As Admin, or in an elevated CMD by running:
Setup.exe /mode:upgrade /IAcceptExchangeServerLicenseTerms
Reboot the server for good measure.
Install the newest Language Pack by browsing to the Language Pack setup files location.
Next, take the server out of Exchange Maintenance Mode, by running the following commands in EMS:
$Computer = $ENV:ComputerName
Set-ServerComponentState $Computer -Component ServerWideOffline -State Active -Requester Maintenance
Resume-ClusterNode $Computer
Set-MailboxServer $Computer -DatabaseCopyActivationDisabledAndMoveNow $False
Set-MailboxServer $Computer -DatabaseCopyAutoActivationPolicy Unrestricted
Set-ServerComponentState $Computer -Component HubTransport -State Active -Requester Maintenance
Restart-Service MSExchangeTransport
Restart-Service MSExchangeFrontEndTransport
Get-ServerComponentState $Computer | ft Component,State –Autosize
Now move on to the next DAG member and follow the steps above.
After DAG members are updated, services are running, and they are back in rotation in the load balancer you can move on to any Edge Servers you're running.
Edge Servers:
On an Edge server, start maintenance mode by running the following in EMS:
$Computer = $ENV:ComputerName
Set-ServerComponentState $Computer -Component ServerWideOffline -State Inactive -Requester Maintenance
Next, make sure that the EMS is closed, or else it will throw PowerShell errors!
Run the CU setup form an elevated CMD:
Setup.exe /mode:upgrade /IAcceptExchangeServerLicenseTerms
Next, stop maintenance mode, in EMS:
$Computer = $ENV:ComputerName
Set-ServerComponentState $Computer -Component ServerWideOffline -State Active -Requester Maintenance
Now you can move on to any other Edge servers, following the same steps.
After you finish with your Exchange servers, you can update any Exchange Management Tools on other machines.
To check build numbers to ensure the CU installed successfully on the Exchange servers, in the EMS, run:
Get-ExchangeServer | fl name,edition,admindisplayversion
Next, you'll want to rebalance your databases in your DAG:
cd $exscripts
.\RedistributeActiveDatabases.ps1 -DagName DAG01 -BalanceDbsByActivationPreference -Confirm:$False
In your monitoring software, stop maintenance mode and start your backups.
A few Post-Install Notes:
If you have any third-party tools like CodeTwo Signature Manager, you'll need to re-activate those...kinda annoying that they don't fix that.
Any changes you have to done to web.config files (Lync IM to OWA Integration for instance) will need to be reconfigured.
If “Discovery Search Mailbox” access warnings are thrown, disable the mailbox, then rerun setup:
Disable the Discovery Search mailbox and re-enable it after installation.
In EMS, run:
Disable-Mailbox “DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}”
Install Exchange 2013 CU
Run the following 2 cmdlets in EMS:
Enable-Mailbox “DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}” -Arbitration
Add-MailboxPermission –Identity ”harriscomputer.com/Service Accounts/Corporate IT/DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}” –User ”Discovery Management1” –AccessRights FullAccess
And you're done!
At the time of this post, CU9 is the latest release and it brings back some much needed features like the ability to keep Sent Items in Shared Mailboxes...why MS took that away I dunno :(
Installing Exchange 2013 CU's:
First, in your monitoring service, put the servers into Maintenance Mode, and stop backup services.
Domain Prep:
Exchange CU's usually contain schema changes, and it's best to run those commands separately, well before you install the CU to give your environment time to replicate changes. And in the case of CU9, it doesn't run ADPrep in the install...stupid.
In an elevated CMD prompt on either a Domain Controller or on one of the Exchange servers, run the following commands:
cd to C:\CU
**Note** Change "C:\CU" to where you extracted the CU setup files.
Setup.exe /prepareSchema /IAcceptExchangeServerLicenseTerms
Setup.exe /prepareAD /IAcceptExchangeServerLicenseTerms
Setup.exe /prepareDomain /IAcceptExchangeServerLicenseTerms
After the commands finish, to check that everything is complete and clean, run:
repadmin /showrepl
CU Installation:
Multirole DAG Members:
I'll be going over how to update multi-role servers that are part of a DAG on hardware load balancers, since that's the most common setup.
First, remove one server from rotation in the load balancer, which will gracefully move connections to another server and not disrupt clients.
I'm using Kemp load balancers so it'll look like this:
Once you have disabled the "real server" set the server into Exchange Maintenance Mode.
Fire up the Exchange Management Shell (EMS) and run the following commands separately:
$Computer = $ENV:ComputerName
Set-ServerComponentState $Computer -Component HubTransport -State Draining -Requester Maintenance
Redirect-Message -Server $Computer -Target odc-exc-mbx-c01.harriscomputer.com
Suspend-ClusterNode $Computer
Set-MailboxServer $Computer -DatabaseCopyActivationDisabledAndMoveNow $True
Set-MailboxServer $Computer -DatabaseCopyAutoActivationPolicy Blocked
Set-ServerComponentState $Computer -Component ServerWideOffline -State Inactive -Requester Maintenance
Once the server is in maintenance mode, now is a good time to install Windows Updates, since it requires a reboot.
After the updates install and you bounce the server, you'll need to uninstall any extra Language Packs in CMD:
cd C:\CU
setup.exe /RemoveUMLanguagePack:fr-CA
**Note** Change "fr-CA" to the pack you have installed.
Next, make sure that the EMS is closed, or else it will throw PowerShell errors! install the CU either by browsing to the extracted files and running setup.exe As Admin, or in an elevated CMD by running:
Setup.exe /mode:upgrade /IAcceptExchangeServerLicenseTerms
Reboot the server for good measure.
Install the newest Language Pack by browsing to the Language Pack setup files location.
Next, take the server out of Exchange Maintenance Mode, by running the following commands in EMS:
$Computer = $ENV:ComputerName
Set-ServerComponentState $Computer -Component ServerWideOffline -State Active -Requester Maintenance
Resume-ClusterNode $Computer
Set-MailboxServer $Computer -DatabaseCopyActivationDisabledAndMoveNow $False
Set-MailboxServer $Computer -DatabaseCopyAutoActivationPolicy Unrestricted
Set-ServerComponentState $Computer -Component HubTransport -State Active -Requester Maintenance
Restart-Service MSExchangeTransport
Restart-Service MSExchangeFrontEndTransport
Verify that services are running by going to the Services Control Panel, or run:
Get-ServerComponentState $Computer | ft Component,State –Autosize
Now move on to the next DAG member and follow the steps above.
After DAG members are updated, services are running, and they are back in rotation in the load balancer you can move on to any Edge Servers you're running.
Edge Servers:
On an Edge server, start maintenance mode by running the following in EMS:
$Computer = $ENV:ComputerName
Set-ServerComponentState $Computer -Component ServerWideOffline -State Inactive -Requester Maintenance
Next, make sure that the EMS is closed, or else it will throw PowerShell errors!
Run the CU setup form an elevated CMD:
Setup.exe /mode:upgrade /IAcceptExchangeServerLicenseTerms
Next, stop maintenance mode, in EMS:
$Computer = $ENV:ComputerName
Set-ServerComponentState $Computer -Component ServerWideOffline -State Active -Requester Maintenance
Now you can move on to any other Edge servers, following the same steps.
After you finish with your Exchange servers, you can update any Exchange Management Tools on other machines.
To check build numbers to ensure the CU installed successfully on the Exchange servers, in the EMS, run:
Get-ExchangeServer | fl name,edition,admindisplayversion
Next, you'll want to rebalance your databases in your DAG:
cd $exscripts
.\RedistributeActiveDatabases.ps1 -DagName DAG01 -BalanceDbsByActivationPreference -Confirm:$False
In your monitoring software, stop maintenance mode and start your backups.
A few Post-Install Notes:
If you have any third-party tools like CodeTwo Signature Manager, you'll need to re-activate those...kinda annoying that they don't fix that.
Any changes you have to done to web.config files (Lync IM to OWA Integration for instance) will need to be reconfigured.
If “Discovery Search Mailbox” access warnings are thrown, disable the mailbox, then rerun setup:
Disable the Discovery Search mailbox and re-enable it after installation.
In EMS, run:
Disable-Mailbox “DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}”
Install Exchange 2013 CU
Run the following 2 cmdlets in EMS:
Enable-Mailbox “DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}” -Arbitration
Add-MailboxPermission –Identity ”harriscomputer.com/Service Accounts/Corporate IT/DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}” –User ”Discovery Management1” –AccessRights FullAccess
And you're done!
Wednesday, September 9, 2015
Exchange 2010 Decommissioning After Migration to Exchange 2013
I'm finally getting around to decommissioning one of our Exchange 2010 environments after migrating to Exchange 2013. I thought I'd share the steps involved to ensure you have completely removed the legacy servers and don't have any orphaned objects hanging around.
The order we'll go in is:
1. Edge Transport Servers
2. Client Access/Hub Transport Servers
3. Mailbox Servers
4. Management Tools on Workstations
Removing the Edge Server:
Make sure that no mailflow is going through the server(s) by using message tracking logs.
Remove the Edge Subscription by running the following command in the Exchange Management Shell (EMS):
Remove-EdgeSubscription -Identity EdgeServer01
**Note** Change "EdgeServer01" to the name of your Edge Server
Go to Programs and Features and run the Uninstall. It will check readiness and then proceed to remove the Edge Role.
Removing Client Access Servers (CAS)/Hub Transport Servers:
In my environment (and most that I've worked on) CAS and HT are installed on the same machine, so we'll be removing them together.
CAS can be removed after they are not serving any clients. You can check the IIS logs to make sure that there are no new connections.
**Note** You will see connections from your Exchange 2013 environment, but that's ok to ignore.
Hub Transport (like the Edge) can be removed after there is no more mailflow. Check message tracking logs to make sure.
**Note** You will see some traffic if there are relay connectors still on the server, or there are DNS entries still pointing to SMTP.
Go to Programs and Features and run the Uninstall. It will check readiness and then proceed to remove the CAS and HT Roles.
Removing Mailbox Servers in a DAG:
Mailbox servers can be removed when there are no mailboxes, no Public Folders, and the Offline Address Books have been removed.
Remove any legacy Offline Address Books by going to Organization Config > Mailbox > Offline Address Book. Right-click the OAB and select "Remove".
Remove the Public Folder Database by running the following in the EMS:
Get-PublicFolderDatabase -Server Mailbox01| Remove-PublicFolderDatabase
**Note** Change "Mailbox01" to your mailbox server name.
Breaking the DAG involves these steps:
1. Removing database copies from the server (unless it is the last DAG member hosting the single copy of the databases)
2. Removing the databases
3. Removing the member from the DAG
4 .Removing the DAG object Active Directory
5. Uninstalling the Mailbox Role
Remove Database Copies:
To remove database copies, move all active copies to another mailbox server:
Move-ActiveMailboxDatabase -Server Mailbox02
Remove the copies from the server:
Get-MailboxDatabaseCopyStatus -Server Mailbox02 | Remove-MailboxDatabaseCopy
Disable Datacenter Activation Coordination (DAC) mode:
Set-DatabaseAvailabilityGroup -Identity DAG01 -DatacenterActivationMode Off
Remove Mailbox Databases:
Remove Mailbox Databases after verifying that they no longer host any mailboxes, by running:
Get-MailboxDatabase -Server Mailbox01
Remove-MailboxDatabase DB01
Remove-MailboxDatabase DB02
Remove-MailboxDatabase DB03
**Note** Change "Mailbox01" to your server name, and "DB01-03" to your database names.
Remove the server from the DAG:
Remove-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer Mailbox02
**Note** Change "DAG01" and "Mailbox02" to match your environment
Repeat the above steps for each DAG member.
Remove the DAG object:
Remove-DatabaseAvailabilityGroup DAG01
After removing the servers from the DAG and removing the databases, you can uninstall the Mailbox Role. Go to Programs and Features and run the Uninstall. It will check readiness and then proceed to remove the Mailbox Role.
Uninstall Exchange Management Tools on Workstations:
Go to Programs and Features and run the Uninstall. It will check readiness and then proceed to remove the Exchange Tools Install.
Now your Exchange 2010 to 2013 is complete!
The order we'll go in is:
1. Edge Transport Servers
2. Client Access/Hub Transport Servers
3. Mailbox Servers
4. Management Tools on Workstations
Removing the Edge Server:
Make sure that no mailflow is going through the server(s) by using message tracking logs.
Remove the Edge Subscription by running the following command in the Exchange Management Shell (EMS):
Remove-EdgeSubscription -Identity EdgeServer01
**Note** Change "EdgeServer01" to the name of your Edge Server
Go to Programs and Features and run the Uninstall. It will check readiness and then proceed to remove the Edge Role.
Removing Client Access Servers (CAS)/Hub Transport Servers:
In my environment (and most that I've worked on) CAS and HT are installed on the same machine, so we'll be removing them together.
CAS can be removed after they are not serving any clients. You can check the IIS logs to make sure that there are no new connections.
**Note** You will see connections from your Exchange 2013 environment, but that's ok to ignore.
Hub Transport (like the Edge) can be removed after there is no more mailflow. Check message tracking logs to make sure.
**Note** You will see some traffic if there are relay connectors still on the server, or there are DNS entries still pointing to SMTP.
Go to Programs and Features and run the Uninstall. It will check readiness and then proceed to remove the CAS and HT Roles.
Removing Mailbox Servers in a DAG:
Mailbox servers can be removed when there are no mailboxes, no Public Folders, and the Offline Address Books have been removed.
Remove any legacy Offline Address Books by going to Organization Config > Mailbox > Offline Address Book. Right-click the OAB and select "Remove".
Remove the Public Folder Database by running the following in the EMS:
Get-PublicFolderDatabase -Server Mailbox01| Remove-PublicFolderDatabase
**Note** Change "Mailbox01" to your mailbox server name.
Breaking the DAG involves these steps:
1. Removing database copies from the server (unless it is the last DAG member hosting the single copy of the databases)
2. Removing the databases
3. Removing the member from the DAG
4 .Removing the DAG object Active Directory
5. Uninstalling the Mailbox Role
Remove Database Copies:
To remove database copies, move all active copies to another mailbox server:
Move-ActiveMailboxDatabase -Server Mailbox02
Remove the copies from the server:
Get-MailboxDatabaseCopyStatus -Server Mailbox02 | Remove-MailboxDatabaseCopy
Disable Datacenter Activation Coordination (DAC) mode:
Set-DatabaseAvailabilityGroup -Identity DAG01 -DatacenterActivationMode Off
Remove Mailbox Databases:
Remove Mailbox Databases after verifying that they no longer host any mailboxes, by running:
Get-MailboxDatabase -Server Mailbox01
Remove-MailboxDatabase DB01
Remove-MailboxDatabase DB02
Remove-MailboxDatabase DB03
**Note** Change "Mailbox01" to your server name, and "DB01-03" to your database names.
Remove the server from the DAG:
Remove-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer Mailbox02
**Note** Change "DAG01" and "Mailbox02" to match your environment
Repeat the above steps for each DAG member.
Remove the DAG object:
Remove-DatabaseAvailabilityGroup DAG01
After removing the servers from the DAG and removing the databases, you can uninstall the Mailbox Role. Go to Programs and Features and run the Uninstall. It will check readiness and then proceed to remove the Mailbox Role.
Uninstall Exchange Management Tools on Workstations:
Go to Programs and Features and run the Uninstall. It will check readiness and then proceed to remove the Exchange Tools Install.
Now your Exchange 2010 to 2013 is complete!
Tuesday, August 25, 2015
Exchange 2013 Deleted Mailbox Not Present In GUI
When you delete/disable a mailbox in Exchange, it won't show up in the Exchange Admin Center (EAC) until the server maintenance runs on it's schedule.
If you have someone delete a mailbox when they shouldn't have, you might need to reconnect the mailbox sooner than the schedule allows.
The Clean-MailboxDatabase cmdlet from Exchange 2010 no longer works in Exchange 2013.
The new cmdlet is Update-StoreMailboxState which, in theory, allows you to update a single mailbox state instead of the entire database.
I was having trouble getting a disabled mailbox to show up after running the command (several times) but I finally found one that works.
What didn't work:
Get-MailboxStatistics -Database “DBName” | Where {$_.DisconnectReason -ne $null } | ForEach { Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$False}
The above command specifies only disconnected mailboxes, which for some reason didn't grab an recently disabled mailboxes; it just showed mailboxes deleted a week ago or longer.
What did work:
Get-MailboxStatistics -Database "DBName" | ForEach { Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$false }
**Note** Change "DBName" to match your environment.
This command updates all mailboxes on the specified database; it does take a bit longer depending on the size of your database but it actually worked, so it was worth the extra few minutes.
If you have someone delete a mailbox when they shouldn't have, you might need to reconnect the mailbox sooner than the schedule allows.
The Clean-MailboxDatabase cmdlet from Exchange 2010 no longer works in Exchange 2013.
The new cmdlet is Update-StoreMailboxState which, in theory, allows you to update a single mailbox state instead of the entire database.
I was having trouble getting a disabled mailbox to show up after running the command (several times) but I finally found one that works.
What didn't work:
Get-MailboxStatistics -Database “DBName” | Where {$_.DisconnectReason -ne $null } | ForEach { Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$False}
The above command specifies only disconnected mailboxes, which for some reason didn't grab an recently disabled mailboxes; it just showed mailboxes deleted a week ago or longer.
What did work:
Get-MailboxStatistics -Database "DBName" | ForEach { Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$false }
**Note** Change "DBName" to match your environment.
This command updates all mailboxes on the specified database; it does take a bit longer depending on the size of your database but it actually worked, so it was worth the extra few minutes.
Saturday, August 22, 2015
Exchange 2013 Compressing Diagnostic Log Directory
I've been having a heck of a time keeping the Exchange 2013 diagnostic logs folder from growing out of control.
The reasoning is: if you have problems with Exchange, it takes less time for Microsoft support to gather logs because they're all there.
The drawback is: if your infrastructure team has a tight hold on storage, and they won't extend your drive, you run out of space very quickly and back pressure will stop mailflow.
Previously, I was running a clean up script, but if I forgot to run it we'd lose space too quickly.
I've found that compressing the diag log folder does a very good job at saving space and there are absolutely no adverse effects on Exchange functions.
On each Exchange 2013 server holding the CAS role, or multi-role, browse to:
C:\Program Files\Microsoft\Exchange Server\V15
Right-click the "Logging" folder and chose "Properties".
Click "Advanced".
Chose "Compress contents to save disk space".
Click OK two times.
Select "Apply changes to this folder, subfolders and files".
Click OK.
You'll get a prompt saying files are in use, just click "Ignore All"
**Note** The files that were in use will eventually be overwritten and all newly created logs will be compressed.
Now, your log folder will shrink tremendously since log files compress very well.
The reasoning is: if you have problems with Exchange, it takes less time for Microsoft support to gather logs because they're all there.
The drawback is: if your infrastructure team has a tight hold on storage, and they won't extend your drive, you run out of space very quickly and back pressure will stop mailflow.
Previously, I was running a clean up script, but if I forgot to run it we'd lose space too quickly.
I've found that compressing the diag log folder does a very good job at saving space and there are absolutely no adverse effects on Exchange functions.
On each Exchange 2013 server holding the CAS role, or multi-role, browse to:
C:\Program Files\Microsoft\Exchange Server\V15
Right-click the "Logging" folder and chose "Properties".
Click "Advanced".
Chose "Compress contents to save disk space".
Click OK two times.
Select "Apply changes to this folder, subfolders and files".
Click OK.
You'll get a prompt saying files are in use, just click "Ignore All"
**Note** The files that were in use will eventually be overwritten and all newly created logs will be compressed.
Now, your log folder will shrink tremendously since log files compress very well.
Exchange 2010/2013 Bulk Add Members to Distribution Groups From CSV
I just had to add a ton of members (283 of them) to a distribution group in Exchange, so I thought I'd write a quick post on importing a list of users from a CSV into the distro group.
First, create a CSV with a list of users and a heading like "EmailAddress". This heading will be used in the PowerShell command later.
**Note** I tend to use email addresses because they're usually more constant than things like usernames, which can be in different formats depending on how many migrations/acquisitions you go through.
You can use Notepad or Excel to build the CSV, and they'll look like this:
Save your new CSV with a distinctive name like BulkDistroGroupMembers.csv and in location like C:\Temp.
Fire up the Exchange Management Shell (EMS) and cd to the location of your CSV:
cd C:\Temp
Then run:
Import-CSV "BulkDistroGroupMembers.csv" | ForEach {Add-DistributionGroupMember -Identity "Distribution Group Name" -Member $_.EmailAddress}
**Note** Change "Distribution Group Name" to the distro group you are adding members to. $_.EmailAddress will correspond to your heading in the CSV. You can name the heading what you like, just make sure that the -Member value matches the heading.
Now your distribution group will quickly have a ton of members.
First, create a CSV with a list of users and a heading like "EmailAddress". This heading will be used in the PowerShell command later.
**Note** I tend to use email addresses because they're usually more constant than things like usernames, which can be in different formats depending on how many migrations/acquisitions you go through.
You can use Notepad or Excel to build the CSV, and they'll look like this:
Fire up the Exchange Management Shell (EMS) and cd to the location of your CSV:
cd C:\Temp
Then run:
Import-CSV "BulkDistroGroupMembers.csv" | ForEach {Add-DistributionGroupMember -Identity "Distribution Group Name" -Member $_.EmailAddress}
**Note** Change "Distribution Group Name" to the distro group you are adding members to. $_.EmailAddress will correspond to your heading in the CSV. You can name the heading what you like, just make sure that the -Member value matches the heading.
Now your distribution group will quickly have a ton of members.
Thursday, August 13, 2015
Exchange 2013 CU9 -MessageCopyForSentAsEnabled Error: A parameter cannot be found...
So, you just updated Exchange 2013 to CU9 and you're excited that Microsoft brought back the ability to save Sent Items in Shared Mailboxes (why they got rid of that I don't know).
When you run the cmdlet Set-Mailbox "shared mailbox name" MessageCopyForSentAsEnabled $True you get an error stating: "A parameter cannot be found that matches parameter name 'MessageCopyForSentAsEnabled'.
The problem is: ADPrep is needed to take advantage of the new features in CU9, and while everyone thought the installer would run PrepareAD, just like all previous installers, it doesn't.
You have to run it separately...luckily, you can run it after the CU9 install (you DO NOT have to reinstall), and you can run it during business hours as it has little impact on replication traffic and will not affect users.
To run ADPrep, open an Elevated Command Prompt, and cd to the CU9 installation directory:
cd C:\Temp\CU9
**Note** C:\Temp\CU9 is where my installer is saved, adjust accordingly.
Then run the setup command:
Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
It happens pretty quickly, and once it's done check your replication to make sure it's clean by running:
repadmin /showrepl
Give it a few minutes depending on your organization size and try to run the MessageCopyForSentAsEnabled cmdlet again:
Now Sent Items will go to the Share Mailbox Sent Items as they should've in the first place.
When you run the cmdlet Set-Mailbox "shared mailbox name" MessageCopyForSentAsEnabled $True you get an error stating: "A parameter cannot be found that matches parameter name 'MessageCopyForSentAsEnabled'.
The problem is: ADPrep is needed to take advantage of the new features in CU9, and while everyone thought the installer would run PrepareAD, just like all previous installers, it doesn't.
You have to run it separately...luckily, you can run it after the CU9 install (you DO NOT have to reinstall), and you can run it during business hours as it has little impact on replication traffic and will not affect users.
To run ADPrep, open an Elevated Command Prompt, and cd to the CU9 installation directory:
cd C:\Temp\CU9
**Note** C:\Temp\CU9 is where my installer is saved, adjust accordingly.
Then run the setup command:
Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
It happens pretty quickly, and once it's done check your replication to make sure it's clean by running:
repadmin /showrepl
Give it a few minutes depending on your organization size and try to run the MessageCopyForSentAsEnabled cmdlet again:
Now Sent Items will go to the Share Mailbox Sent Items as they should've in the first place.