Recently at a client we configured some mailboxes as Resources.
It was then decided that they would be better off as shared mailboxes, as they could be used for other tasks. Therefore the mailbox was converted to shared:
set-mailbox mailboxname -type:shared
However any emails sent to the new Shared mailbox were continuing to go in to the Deleted Items folder. This is the standard behaviour for a resource mailbox, as it is only expecting to get calendar items.
The key is to disable the Calendar processing. You can see the current setting thus:
get-calendarprocessing mailboxname | select identity, AutomateProcessing
To disable it completely, you need to change the value of AutomateProcessing to none
set-calendarprocessing mailboxname -AutomateProcessing None
In this case, the folder still needed to accept and process calendar entries, so we changed it to AutoUpdate.
set-calendarprocessing mailboxname -AutomateProcessing AutoUpdate
The full parameters are discussed in the Technet article:
http://technet.microsoft.com/en-us/library/dd335046(v=exchg.141).aspx
Kudos to Holly at the client for finding the value which I had completely forgotten about!
Just deployed a new Kemp Load Balancer with a client which promptly broke their cross site DAG.
Usual horrible error:
[PS] C:\Windows\system32>Get-DatabaseAvailabilityGroup -Status
WARNING: Unable to get Primary Active Manager information due to an Active Manager call failure. Error: An Active
Manager operation failed. Error The Microsoft Exchange Replication service may not be running on server XXX-3. Specific
RPC error message: Error 0x6ba (The RPC server is unavailable) from cli_AmGetDeferredRecoveryEntries.
(server xxx-3 is the remote server).
Discovered that the problem was due to an option enabled on the Kemp called Enable Server NAT (SNAT). You can find this under System Configuration, Miscellanious Options, Network Options. Disabling that corrected the issue almost immediately. Seems that the NAT broke the DAG.
Looks like Blackberry are running an offer for free BES 10 CALs.
Activate a Blackberry 10 device and get two free CALs.
http://uk.blackberry.com/business/blackberry-10/blackberry-10-ready/license-offer.html
Activate a Blackberry 10 device between July 1st and August 31st 2013 and for each device you will get TWO free CALs. These CALS are the EMM Corporate type so will work for Blackberry 10 devices and Android/iPhone. At current prices they are worth almost £70 each.
The BES 10 software is free (trial download on the link above).
The window to claim the free CALs is quite small, so Blackberry have provided a link to be told when the registration process is open.
I was recently asked to look at an Exchange server giving the common PowerShell connection failure due to Kerberos authentication.
The following error occurred while attempting to connect to the specified Exchange server 'rpi-exchange.rp.local':
"The attempt to connect to http://rpi-exchange.rp.local/PowerShell using "Kerberos" authentication failed: Connecting to the remote server failed with the following error message: The connection to the specified remote host was refused. Verify that the WS-Management service is running on the remote host and configured to listen for requests on the correct port and HTTP URL. For more information, see the about_Remote_Troubleshooting Help topic. "
The usual reasons for this error are well documented and I am not covering them here. After spending an hour going through the usual suspects, I started to look for anything else, as this was giving a Connection Refused error, which wasn't hugely documented past the Remote PowerShell permission.
I then had a brainwave. I was working on a system in a school. Schools have pretty restricted Internet access in most cases. This usually means a proxy.
Netsh winhttp show proxy
That command immediately showed there was a proxy, running
Netsh winhttp reset proxy
Cleared the proxy settings and allowed the Exchange Management Console to start correctly.
The client was then advised to check their proxy configuration settings, specifically the exceptions list so that the correct ones were in place, as I feared that next time Group Policy applied the proxy settings, the change would be reset.
From conversations with clients, it would appear that a lot of people are unaware that Exchange 2010 Service Pack 1 is no longer supported.
I am still seeing clients who haven't upgraded. These range from SBS users right up to multi site Enterprise clients.
The Microsoft support policy on service packs is that when a new service pack is released, the previous service pack only is supported for a further 12 months.
The support of Exchange 2010 SP1 ended in January 2013, Service Pack 2 ends in April of 2014.
If you are still on the original release, known as RTM, then support ended in November of 2011.
This shouldn't be confused with support of the product Exchange 2010, which will be supported (as long as it is on the latest service pack) until 2015, with extended support until 2020.
The full table for support can be seen here:
http://semb.ee/e2010dates
If you are curious about Exchange 2007, then those dates can be seen here:
http://semb.ee/e2007dates
