At a client site yesterday, the help desk were provisioning new users with phone extension and for one they came across the error below.
The user was already assigned this extension in Lync and AD had the correct information. Normally when an extension is in use they would not have been able to add the extension in link.
In order to resolve this issue – I ran the Get-UMMailbox command. I piped the output to a text file and found that the extension above was still in use on a disabled user. Once removed we were able to assign the extension to the new user.
Recently had an issue where a user who was a carried over from Exchange Server 2003 way back when had multiple corrupt items. When he was originally migrated to Exchange Server 2010 there were a number of items which so how got corrupt. This inhibited his search abilities. With the New-MailboxRepairRequest command in Exchange 2016 I was able to resolve this issue.
I ran the repair against all options:
Once complete we recreated the user’s .OST file since he works in cached mode.
You can find more info on this at Technet:
If you are sending emails to a Journaling connector and do not wish to journal voicemail messages for legal or business purposes you can disable this feature with the following command.
Set-TransportConfig -VoicemailJournalingEnabled $false
A client recently asked to have a retention for mail items but to leave calendar and tasks untouched. When in the ECP the option to create a specific retention tag for calendar items or tasks is missing. You must do this through Powershell.
Below is the command I used for both Calendar items and Tasks
New-RetentionPolicyTag “Name of Retention Policy Tag” -Type Calendar -RetentionEnabled $false -RetentionAction DeleteAllowRecovery
Do the same for Tasks replacing Calendar for Tasks in the Type field. Once run you can then add these Retention Policy Tags to your Retention Policy.
I have noticed on occasion that after suspending a database copy for a prolonged period of time the ContentIndex State may be stuck in a Suspended state.
You can resolve this situation by reseeding the ContentIndex only from the Active copy.
Update-MailboxDatabaseCopy “DatabaseName\ExchangeServer” -CatalogOnly
The other day while updating Exchange 2016 to the latest CU, I ran across the following error message:
An Active Manager operation failed. Error: The database action failed. Error: Move for database ‘DatabaseName’ was suppressed because too many moves have happened recently. 3 moves have happened within 01:00:00
Before updating, I had applied the latest security patches plus needed to update .NET Framework so I was moving datastores back and forth.
To get around this error you can use the SkipMoveSuppressionChecks parameter.
Move-ActiveMailboxDatabase -Identity ‘DatabaseName’ -ActivateOnServer ‘ExchangeServer’ -SkipMoveSuppressionChecks
Yesterday, I was in the process of uninstalling the UM Role from an Exchange Server 2010 Server which we had set to decommission now that we are migrating to Exchange Server 2016.
Running Setup /mode:Uninstall from the following directory C:\Program Files\Microsoft\Exchange Server\V14\Bin – I ran into my first error.
The tmlisten service is our Officescan Antivirus which was running at the time. I promptly unloaded the service and tried the uninstallation process again which generated the following error:
C:\Program Files\Microsoft\Exchange Server\V14\Bin\ManageScheduleTask.ps1 is not recognized as the name of a cmdlet, function, script file, or operable program.
I found a possible solution here:
Moved the ManageScheduletask.ps1 and ManageScheduletask.strings into the Bin directory from the Scripts directory. Apparently it may be a bug, re-ran the uninstalltion process but unfortunately the process failed again.
This time I was in a far worse situation since I had a half uninstalled version of Exchange on my UM server. The application was no longer visible in Programs and Features but the directory was clearly there (albeit missing files) and running Get-ExchangeServer clearly displayed the Exchange server in question.
I didn’t want to manually remove the server entries with ADSIEdit so I reinstalled Exchange Server 2010 SP3 only (we were at CU level 18 ). Then reran the uninstallation process again.
The process failed yet again this time Setup could not find the following file ConfigureNetworkProtocolParameter.ps1 under the Scripts directory. Checked this location and indeed the file was missing because I cross referenced it with another Exchange server. I copied this file into the directory reran the process and was finally able to perform a clean uninstallation of Exchange.