Think carefully before enabling dedup! Then after thinking about it use compression instead.
From the release notes of FreeNAS 8.3.1-RELEASE-p2
Found a bug in the Exchange 2013 install, similar to 2010. It appears that when the Scripting Agent is enabled in your Exchange org (via Enable-CmdletExtensionAgent “Scripting Agent”) the Exchange 2013 installer will fail with the error below.
The following error was generated when “$error.Clear();
” was run: “Provisioning layer initialization failed: ‘”Scripting Agent initialization failed: “File is not found: ‘E:\Program Files\Microsoft\Exchange Server\V15\Bin\CmdletExtensionAgents\ScriptingAgentConfig.xml’.””‘”.
There are a few ways to work around the issue.
- Disable the Scripting Agent extension
Disable-CmdletExtensionAgent “Scripting Agent”
- Copy the ScriptingAgentConfig.xml file to the “(intended install drive letter):\Program Files\Microsoft\Exchange Server\V15\Bin\CmdletExtensionAgents” folder on the new server and go through with the install as normal.
I’ve tried copying the current ScriptingAgentConfig.xml file to the (install media)\serverroles\common\cmdletextensionagents folder, but it doesn’t seem to get moved over during the install. That would be ideal in my situation as I don’t edit the config often, if at all.
Been trying to migrate some mailboxes to from 2010 to 2013 for testing, and some small/empty ones move fine, but larger mailboxes fail to move, showing long “Stalled duration” in the Migration Batch details.
Queued duration: 00:00:08 In-progress duration: 00:11:51 Synced duration: Stalled duration: 03:16:33
The issue is caused by a Content Indexing failure on the target database, caused by what is apparently a missing element of the AD Prep portion of setup.
The problem is documented at http://support.microsoft.com/kb/2807668
I’m running CU1 (released April 2013) and the KB article was posted in January. so it’s not clear why this still wasn’t addressed.
Of the 2 fixes listed in the KB, I chose Method 1 because it felt like a more reliable, permanent fix. I didn’t want to run into this again when adding a new mailbox server.
The KB directs you to add a ContentSubmitters group to AD, set permissions on it, and restart Exchange search services. It took a few more steps in my case to actually solve the issue. I also had to stop the services, remove the current content index and start services again.
The steps all together were:
- Add a ContentSubmitters group to AD.
I did this manually, creating it as a Security enabled Universal group.
- Assign Network Service and Administrators groups the “Full Access” permission (I think they mean “Full Control” permission).
Ended up using the PowerShell commands
Add-ADPermission -Id ContentSubmitters -User “Network Service” -Access Rights GenericAll
Add-ADPermission -Id ContentSubmitters -User “Administrators” -Access Rights GenericAll
- Stop the Microsoft Exchange Search and Microsoft Exchange Search Host Controller services
- Delete the Content Index data for the affected database(s)
This is the folder with a GUID name inside the folder where the mailbox database lives.
- Start the Microsoft Exchange Search and Microsoft Exchange Search Host Controller services.
After a few minutes, the status of the content index went from FailedAndSuspended to Crawling, at which point the mailbox move resumed.