We have recently published two articles to help cleanup recoverable items when a mailbox is placed on In-Place Hold or Litigation Hold or has single item recovery enabled, you’ll want to preserve the mailbox data until the hold is removed or single item recovery is disabled. In this case, you need to perform more detailed steps to clean up the Recoverable Items folder.
The detailed steps are located here:
Office 365: Delete items in the Recoverable Items folder of cloud-based mailboxes on hold – Admin Help
On-Premises: Clean up or delete items from the Recoverable Items folder
I just posted a new blog on the Exchange Team Blog titled “PAW your way into Office 365 Migrations” Go check it out if you want to learn about Protocol Agnostic Workflow aka PAW and how it will enhance the experience of migrating your data to Office 365.
Source: PAW your way into Office 365 Migrations – You Had Me At EHLO…
Coming to the next CUs for Exchange 2013 and Exchange 2016 there are some changes to how the Exchange Management Shell (EMS) connects to Exchange. In previous versions, we have seen that customers who were reliant on a load balanced solutions for third party apps and scripts may get routed to a non-Exchange 2016 server. This would lead customers to some broken administrative experiences based on the reliance of Exchange 2016 cmdlets and features. Today we will dive deeper into these changes to help the Exchange Administrator understand how these changes will affect their Exchange Organization.
Check out the full article at The Exchange Team Blog
I have created a script will gather the MRM configuration for a given user. It will collect the current MRM Policy and Tags for the Exchange Administrators to be able to troubleshoot MRM issues. If you have MRM woes and need to collect data this script will do it for you.
I was on my server and everything seemed fine. Performance was great however I kept getting the error following error every time I went to modify a database or show command logging:
“The window couldn’t be opened because your computer is low on memory. Please close some windows and try again.”
I was able to go to another machine and all was well so I started searching on this and apparently ieproxy.dll was not registered. I ran the below and it resolved my issue.
1. Open a CMD window
2. Navigate to C:\Program Files\Internet Explorer
3. Run the following command line:
When installing Exchange 2013 from PowerShell in my lab I ran into an issue and the server failed installing the Client Access Role.
Welcome to Microsoft Exchange Server 2013 Service Pack 1 Unattended Setup
File copy complete. Setup will now collect additional information needed for installation.
Mailbox role: Transport service
Mailbox role: Client Access service
Mailbox role: Unified Messaging service
Mailbox role: Mailbox service
Client Access role: Front End Transport service
Client Access role: Client Access Front End service
Performing Microsoft Exchange Server Prerequisite Check
Configuring Prerequisites COMPLETED
Prerequisite Analysis COMPLETED
Configuring Microsoft Exchange Server
Preparing Setup COMPLETED
Stopping Services COMPLETED
Copying Exchange Files COMPLETED
Language Files COMPLETED
Restoring Services COMPLETED
Language Configuration COMPLETED
Exchange Management Tools COMPLETED
Mailbox role: Transport service COMPLETED
Mailbox role: Client Access service FAILED
The following error was generated when “$error.Clear();
Install-ExchangeCertificate -WebSiteName “Exchange Back End” -services “IIS, POP, IMAP” -DomainController $RoleDomainController -InstallInTrustedRootCAIfSelfSigned $true
if ($RoleIsDatacenter -ne $true -And $RoleIsPartnerHosted -ne $true)
Install-AuthCertificate -DomainController $RoleDomainController
” was run: “Could not grant Network Service access to the certificate with thumbprint 1C5101B4BE0AF6CBD6A39FD413436E2649B0124 because a cryptographic exception was thrown.”.
The Exchange Server setup operation didn’t complete. More details can be found in ExchangeSetup.log located in the <SystemDrive>:\ExchangeSetupLogs folder.
Since I was already in PowerShell I went ahead and added the Exchange SnapIn since the Exchange Management Tools were installed and checked for the thumbprint listed above
PS C:\Exchange\Setup> Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
PS C:\Exchange\Setup> Get-ExchangeCertificate
Thumbprint Services Subject
———- ——– ——-
4DEAE2C0FD7657546E5BE9C326DFD463F6F3AB3D ….S.. CN=ex02
59A4489083B12076D397B30B27B53397194A2B2C ….S.. CN=Microsoft Exchange Server Auth Certificate
046880AF472664A815FFBC2252860A2E2111231B ……. CN=WMSvc-EX02
As we can see it’s not listed so I decided to look at all the certificates loaded on the server.
I then opened up MMC and added certificates for the local computer and see 4 certificates, however Exchange is only seeing 3. I am not sure where the certificate for the FQDN came from since the labs was just built today (8-10-14). The other three were supposed to be there after an Exchange Server install.
I backed up the certificate and removed it and then re-ran the installation and it resolved the issue.
Unknown at this time. I have been able to reproduce the issue but I do not know why the certificate is there (possible lab image issue). Time to try to debug the issue. J
Sometimes there arises a scenario where you may want to disable remote PowerShell access for your users in Office 365. The main reason for doing so would be to prevent rogue admins, users, or even compromised user accounts from being able to do anything malicious with your tenant.
By default, all users will have remote PowerShell access to your Office 365 Organization. Now RBAC Policies prevent them from doing a whole lot (if they are non-administrative users). However if an account gets compromised there could be issues.
The cmdlet below turns off remote PowerShell for a particular user. You can use this to disable PowerShell for all user’s but remember to do not include the Administrators account or you will not be able to run the Hybrid Configuration Wizard or do any management to the Office 365 Tenant that would require you to use PowerShell and make for a very bad day.
Set-User -Identity <ALIAS> -RemotePowerShellEnabled:$False