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
So apparently Microsoft has removed the settings options from the GUI in Windows Server 2016. You can still change it a number of ways; regedit, sconfig, or GPO.
I found using sconfig the easiest for one of servers but it is best to use a GPO for larger number of servers.
A better article on this can be found here:
I have been working with Nimble Storage SANs for a few years now and I believe their storage solutions are perfect for midsized firms who may or may not have the budget to maintain a full time Storage Engineer.
The user interface is clean and intuitive, upgrades are extremely straight forward, support is great, and I don’t believe any other storage vendor can really compete with Infosight.
The other day at a client site, we came a cross an issue in regards to encryption. Encryption at Rest was enabled for some volumes and the
This is pretty much a set and forget option, however this does not mean you will never have to enter the encryption passphrase. If your SAN loses power you will be forced to enter the password. So keep it in a safe place, if you lose it you are pretty much S.O.L. You cannot change the passphrase without knowing the current one. In order to recover the passphrase the SAN would need to be rebuilt or you would need to migrate all data off to unencrypted volumes. So moral of the story never ever ever lose that password! 🙂
When copying data, if the folder naming structure to long you may come across the following error.
In order to get around this you can either do one of two options:
- Rename to a smaller naming structure
- Use robocopy.exe to copy the data over to the new location – %Systemroot%\System32\robocopy.exe
We are in the process of removing our old WSUS server that has faithfully served our client for main years. However now it is time to restore the servers pointing to this box back to the default value of Windows Update.
You can do this either with Powershell or editing the registry.
- Stop the Windows Update service
- Open regedit
- Find the following key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\
- Right-Click and delete the registry key Windows Update
- Restart the Windows update Service
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.
The simple straight forward method to truncate logs in the occasion where you find yourself running out of disk space and do not have additional free space to spare.
Open SQL Studio > Select the database in question > Right click and Select Properties
From the Database Properties Window select Option and change the Recovery model to Simple.
Then Right click the database and select Tasks > Shrink > Files. Change the File Type to Log > Select OK
This will truncate the .ldf file.