Exchange 2010

All posts tagged Exchange 2010

In the first two parts of the blog series about troubleshooting federated sharing we had a look at the infrastructure and configuration which is required. Besides this we did some basic troubleshooting on the components involved during federated sharing. In this part we will look at some examples which I gathered during troubleshooting a federated sharing issue.

Below you will see an example of an error which was received when trying to retrieve the free/busy information from a user hosted on another Exchange environment.

Process 1212: ProxyWebRequest FederatedCrossForest from S-1-5-21-1671710892-3805255249-3875359145-102309 to https://mail.domain.com/ews/exchange.asmx/WSSecurity failed. Caller SIDs: WSSecurity. The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

   at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)

   at System.Net.PooledStream.EndWrite(IAsyncResult asyncResult)

   at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)

   — End of inner exception stack trace —

   at System.Web.Services.Protocols.WebClientAsyncResult.WaitForResponse()

   at System.Web.Services.Protocols.WebClientProtocol.EndSend(IAsyncResult asyncResult, Object& internalAsyncState, Stream& responseStream)

   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.Proxy.Service.EndGetUserAvailability(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.FreeBusyApplication.EndProxyWebRequest(ProxyWebRequest proxyWebRequest, QueryList queryList, Service service, IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequest.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.AsyncWebRequest.EndInvokeWithErrorHandling():. The request information is ProxyWebRequest type = FederatedCrossForest, url = https://mail.domain.com/ews/exchange.asmx/WSSecurity

Mailbox list = <Johan@domain.com>SMTP:Johan@domain.com, Parameters: windowStart = 10/1/2013 10:00:00 AM, windowEnd = 10/31/2013 10:00:00 AM, MergedFBInterval = 30, RequestedView = Detailed

. —> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

   at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)

   at System.Net.PooledStream.EndWrite(IAsyncResult asyncResult)

   at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)

   — End of inner exception stack trace —

   at System.Web.Services.Protocols.WebClientAsyncResult.WaitForResponse()

   at System.Web.Services.Protocols.WebClientProtocol.EndSend(IAsyncResult asyncResult, Object& internalAsyncState, Stream& responseStream)

   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.Proxy.Service.EndGetUserAvailability(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.FreeBusyApplication.EndProxyWebRequest(ProxyWebRequest proxyWebRequest, QueryList queryList, Service service, IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequest.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.AsyncWebRequest.EndInvokeWithErrorHandling()

   — End of inner exception stack trace —

. Name of the server where exception originated:CAS01. Make sure that the Active Directory site/forest that contain the user’s mailbox has at least one local Exchange 2010 server running the Availability service. Turn up logging for the Availability service and test basic network connectivity.

When looking at the marked text you will see the actual cause, a certificate issue. So how to deal in this case? The first step you can take is try to access the Exchange Web Services of the other Exchange environment. In this case we can do it by browsing to https://mail.domain/com/ews/exchange.asmx/WSSecurity what will probably happen is that you receive a certificate warning. And that is exactly why the lookup fails. The certificate from the remote Exchange environment is not valid according to the validation procedure. However when you open it in a browser you will see the reason why the certificate is not trusted. This can be caused by several things among them:

  • Certificates is signed by a root CA which is not trusted
  • Name on the certificate is incorrect

In this case the root CA was not trusted by the Exchange environment. By importing the root CA in the Enterprise Trusted Root folder of the CAS the problem was solved.

The second one was pretty hard to troubleshoot but the solution to solve it was pretty easy. Again the error is marked in the text below. The error tells you that the other side did close the connection. OK nice and now what? In this case you will need to search in the IIS logs on the CAS of the target Exchange environment to see what happens when traffic from your Exchange environment arrives at the CAS.

Process 1212: ProxyWebRequest FederatedCrossForest from S-1-5-21-1671710892-3805255249-3875359145-102309 to https://mail.domain.com/ews/exchange.asmx/WSSecurity failed. Caller SIDs: WSSecurity. The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. —> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. —> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

   at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult)

   at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult)

   — End of inner exception stack trace —

   at System.Net.Security._SslStream.EndRead(IAsyncResult asyncResult)

   at System.Net.TlsStream.EndRead(IAsyncResult asyncResult)

   at System.Net.PooledStream.EndRead(IAsyncResult asyncResult)

   at System.Net.Connection.ReadCallback(IAsyncResult asyncResult)

   — End of inner exception stack trace —

   at System.Web.Services.Protocols.WebClientAsyncResult.WaitForResponse()

   at System.Web.Services.Protocols.WebClientProtocol.EndSend(IAsyncResult asyncResult, Object& internalAsyncState, Stream& responseStream)

   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.Proxy.Service.EndGetUserAvailability(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.FreeBusyApplication.EndProxyWebRequest(ProxyWebRequest proxyWebRequest, QueryList queryList, Service service, IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequest.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.AsyncWebRequest.EndInvokeWithErrorHandling():. The request information is ProxyWebRequest type = FederatedCrossForest, url = https://mail.domain.com/ews/exchange.asmx/WSSecurity

Mailbox list = <Johan@domain.com>SMTP:Johan@domain.com, Parameters: windowStart = 9/29/2013 12:00:00 AM, windowEnd = 11/10/2013 12:00:00 AM, MergedFBInterval = 30, RequestedView = MergedOnly

. —> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. —> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. —> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

   at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult)

   at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult)

   — End of inner exception stack trace —

   at System.Net.Security._SslStream.EndRead(IAsyncResult asyncResult)

   at System.Net.TlsStream.EndRead(IAsyncResult asyncResult)

   at System.Net.PooledStream.EndRead(IAsyncResult asyncResult)

   at System.Net.Connection.ReadCallback(IAsyncResult asyncResult)

   — End of inner exception stack trace —

   at System.Web.Services.Protocols.WebClientAsyncResult.WaitForResponse()

   at System.Web.Services.Protocols.WebClientProtocol.EndSend(IAsyncResult asyncResult, Object& internalAsyncState, Stream& responseStream)

   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.Proxy.Service.EndGetUserAvailability(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.FreeBusyApplication.EndProxyWebRequest(ProxyWebRequest proxyWebRequest, QueryList queryList, Service service, IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequest.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.AsyncWebRequest.EndInvokeWithErrorHandling()

   — End of inner exception stack trace —

. Name of the server where exception originated: CAS01. Make sure that the Active Directory site/forest that contain the user’s mailbox has at least one local Exchange 2010 server running the Availability service. Turn up logging for the Availability service and test basic network connectivity.

Search for traffic destined to /ews/exchange.asmx/WSSecurity and you will probably find the error that did occur. Normally when everything works a 200 will be displayed. If you do receive a 4XX error then verify that the federation with the Microsoft Federation Gateway works correctly as explained in the first part. Besides this verify that WSSecurity is enabled on the Autodiscover and EWS directory.

However you might get other errors, in this case it was a 500 error. What this means and that it doesn’t know how to deal with the traffic which arrives and will close the connection. If this happens make sure WSSecurity is enabled on the virtual directories for Autodiscover and EWS. When this is confirmed verify that the svc-integrated handler is assigned to both the Autodiscover and EWS. If this is both configured correctly everything should be OK but why doesn’t it work?

In some occasions it may happen that EWSSecurity is correctly enabled but for some reason IIS doesn’t pick this up. If this happens an iisreset will fix your issue and you will be able to retrieve the free/busy information from the other Exchange organization.

Here ends the series of troubleshooting federated sharing. I am aware there might be other solution for the issues you might find during the implementation but these were just two examples of issues I found.

I hope you liked this series and if you have any questions use the contact form on the site to send me a message or ask your question by posting a comment.

 By using federated sharing it is possible to exchange free/busy informative between different Exchange organizations. This can be done by using the Microsoft Federation Gateway (MSFG) when no direct trust exists between the Active Directories. The MSFG is in this case responsible for providing a ticket which is used for authentication. By using a ticket a CAS can contact the CAS from the other organization to retrieve the free/busy information.

To use this feature several things will need to be configured:

  • trust with the Microsoft Federation Gateway
  • organizational relationship must be configured
  • autodiscover and EWS must allow WS Security authentication
  • the reverse proxy needs to allow unauthenticated traffic to the following url’s:
    • /EWS/exchange.asmx/WSSecurity
    • /autodiscover/autodiscover.svc/WSSecurity
    • /autodiscover/autodiscover.svc

Several sites contain a step-by-step plan on how to configured this. An overview of those sites can be found on the end of this article.

When you setup these things everything should work, indeed should. In most cases it will work but in some cases you will need to perform some troubleshooting. In this serie of blogs we will have a look how you can validate that it works and perform some troubleshooting in case something doesn’t work.

But how can you troubleshoot these issues? First of all it is very useful if you have a contact person who has access to the other Exchange organization. In most cases this isn’t a big issue but when using Office 365 or another form of hosting this can be very hard sometimes.

To start the troubleshooting process you mostly would like to verify your own Exchange organization first. Things that could be checked are:

  • verify if autodiscover allows WS Security for authentication
  • verify the external EWS url
  • verify if Exchange Web Services will allow WS Security for authentication

If your Exchange organization contains multiple CAS then Powershell is your friend and you can use several cmdlets to verify the steps above:

Get-AutodiscoverVirtualDirectory|select server, WSSecurityAuthentication

Get-AutodiscoverVirtualDirectory

You will get an output like above. Verify if the value of the column WSSecurityAuthentication is set to true

If WSSecurity is not true then use the following cmdlet to enable it:

Get-AutodiscoverVirtualDirectory|Set-AutodiscoverVirtualDirectory -WSSecurityAuthentication:$true

Using this cmdlet the authentication method will be configured but to offer this authentication type you will need to perform an IISReset. Additional you can verify if the svc-integrated handler is attached to the autodiscover virtual directory:

IIS

Next step is to verify the Exchange Web Services, this can be done by using the Get-WebServicesVirtualDirectory cmdlet:

Get-WebServicesVirtualDirectory|select server, ExternalUrl, WSSecurityAuthenticationcmdle

Get-WebServicesVirtualDirectory

Again the same rule apples WSSecurityAuthentication needs to be set to true. Besides this the ExternalUrl needs to contains a valid value. This url needs to accessible from the internet. If this is not the case it simply won’t work.

In case that WSSecurity is not true enabled it by using the following cmdlet:

Get-WebServicesVirtualDirectory|Set-WebServicesVirtualDirectory -WSSecurityAuthentication:$true

The same applies for EWS as it did for autodiscover perform an IISReset to activate the authentication method. Besides this verify if the ws-security handler is attached to the EWS virtual directory.

If no external url is configured you will need to configure one. Before you do this make sure the certificate contains all the correct names. If you will configure a value but it is not part of your certificate you will get errors.

To verify if the certificate contains the correct names we will use Powershell again:

Get-ExchangeCertificate|? {$_.Services -like “*IIS*”}|select Subject, CertificateDomains|FL

Verify if the CertificateDomains contain the FQDN you are planning to use for EWS, for example mail.domain.com of ews.domain.com. If this name is not on the certificate you will need to renew your certificate.

If the certificate contains the name for the external URL then you can continue configuring it:

Get-WebServicerVirtualDirectory|Set-WebServicesVirtualDirectory -Externalurl “https://ews.domain.com/EWS/exchange.asmx”

Using the cmdlet above the external URL on all Client Access Servers will be configured the same. REMARK: in some scenarios this is not what you want. Please verify if this is the case in your scenario before configuring the external url.

When this has been configured and validated it is time to verify the Federation Trust and the Organization Relationship.

This can be done by starting with Test-FederationTrustCertificate which will verify if the certificate used for the trust is correct and is installed on all CAS. During the creation of the trust the self-signed certificate will normally be distributed to all CAS in your environment. But in some cases this may not happen. If this is the case the CAS will be unable to authenticate against the Federation Gateway of Microsoft which will eventually result the autodiscover process to fail.

Test-FederationTrustCertificate

Test-FederationTrustCertificate

Verify that the State column for all CAS contain the value installed.

Additionally you can run the Test-FederationTrust cmdlet to verify if the Federation Trust really works. By default this cmdlet will use the extest account:

Test-FederationTrust

If you don’t have an extest account or you would like to use another user add the UserIdentity parameter:

Test-FederationTrust -UserIdentity user@domain.com

This cmdlet will perform several tests and will output the results on the screen, verify if no errors did occur.

As final step of the process you can verify the Organization Relationship. This is only applicable if the other organization has issues when looking up the free/busy information for your mailboxes. By using an organization relationship you will give the other organization permission to retrieve free/busy information of your organization. If not all domains are listed here it can cause strange issues such as it works for domain A but not for domain B while they are located in the same Exchange environment.

To troubleshoot these kind of issues you can use two cmdlets:

  • Get-OrganizationRelationShip,  retrieves the current configuration
  • GetFederationInformation, will send an autodiscover request to the other organization to retrieve the configuration

The following parameters are important in this case:

  • DomainNames
  • TargetApplicationUri
  • TargetAutoDiscoverEpr

One remark must be made about the DomainNames parameter. In some cases this parameter doesn’t have to be the same for both cmdlets. Some organizations only want to share free/busy information with a specific domain and not all domains hosted by the other Exchange organization.

In this part of the series we did have a look which configuration items you will need to verify in your Exchange organization. Besides this we did had a look on how to fix them if they are configured incorrectly.

In the second part we will have a closer look at the reverse proxy and client part of troubleshooting.

Below are some pages which contain use full information about federated sharing:

Office 365 Community: How to configure TMG for Office 365: open
TechNet: How does Federated Calendar sharing work in Exchange 2010?: open
TechNet: Exchange 2013: Sharing: open

Exchange 2010 SP3 Rollup 2 released

Microsoft has released Exchange 2010 SP3 Rollup 2 yesterday. This rollup will fix the following issues:

  • 2837926 Error message when you try to activate a passive copy of an Exchange Server 2010 SP3 database: “File check failed”
  • 2841150 Cannot change a distribution group that contains more than 1,800 members by using ECP in OWA in an Exchange Server 2010 environment
  • 2851419 Slow performance in some databases after Exchange Server 2010 is running continuously for at least 23 days
  • 2853899 Only the first page of an S/MIME signed or encrypted message is printed by using OWA in an Exchange Server 2010 environment
  • 2854564 Messaging Records Management 2.0 policy can’t be applied in an Exchange Server 2010 environment
  • 2855083 Public Folder contents are not replicated successfully from Exchange Server 2003 or Exchange Server 2007 to Exchange Server 2010
  • 2859596 Event ID 4999 when you use a disclaimer transport rule in an environment that has Update Rollup 1 for Exchange Server 2010 SP3 installed
  • 2860037 iOS devices cannot synchronize mailboxes in an Exchange Server 2010 environment
  • 2861118 W3wp.exe process for the MSExchangeSyncAppPool application pool crashes in an Exchange Server 2010 SP2 or SP3 environment
  • 2863310 You cannot send an RTF email message that contains an embedded picture to an external recipient in an Exchange Server 2010 SP3 environment
  • 2863473 Users cannot access Outlook mailboxes that connect to a Client Access server array in an Exchange Server 2010 environment
  • 2866913 Outlook prompts to send a response to an additional update even though the response request is disabled in an Exchange Server 2010 environment
  • 2870028 EdgeTransport.exe crashes when an email message without a sender address is sent to an Exchange Server 2010 Hub Transport server
  • 2871758 EdgeTransport.exe process consumes excessive CPU resources on an Exchange Server 2010 Edge Transport server
  • 2873477 All messages are stamped by MRM if a deletion tag in a retention policy is configured in an Exchange Server 2010 environment

Especially when you are planning to migrate from Exchange 2010 from Exchange 2003 or Exchange 2007 this rollup is recommended. The rollup fixes an issue which can occur with Public Folder replication between Exchange 2003/2007 and Exchange 2010. Because replicating the public folder content is one of the steps you might see this issue if you won’t deploy Exchange 2010 SP3 rollup 2.

The second interesting thing in the release notes is a fix for the MsExchangeSyncAppPool which crashes. This issue occurs only when offering ActiveSync services to your end-users and you will use Apple devices. In this case it can happen that the CPU usage on the CAS is high (between 80% and 100%). Users might in this case not be able to sync their mailbox content because throttling is applied. Cause of this issue is the throttling mechanism. Exchange 2010 SP3 Rollup 2 contains a fix for this issue which should prevent this issue from occurring again.

Looking at the third issue you may think what? Slower performance which is experienced by users when their mailbox is hosted in a database which his created after Exchange 2010 SP3. This problem occurs only if the database is online for more then 23 days.

You can download Exchange 2010 SP3 rollup 2via the link below:

download

Deploy Exchange 2013 CU’s

This weeks the second version of the second cumulative update has been released for Exchange 2013. As you may already know Microsoft has changed his update process completely with the introduction of Exchange 2013. No more rollups and only cumulative updates (CU’s).

A pretty big change as the CU’s require you to make changes to the AD also as step of the update process. For those not familiar with rollups of Exchange 2010, the rollups where just bit updates and did not include AD changes. In Exchange 2010 the AD changes where only included in service packs.

CU’s are a complete install of Exchange 2013. So if you plan to install Exchange 2013 in the future you will only need to install the latest CU and you’re done.

But what has changed from deployment standpoint? Well pretty much because we now have to think of the Managed Availability feature of Exchange 2013. This feature will continually monitor the environment and takes action if necessary.

You can compare it with placing a node in maintenance mode in a load balancer. Although with placing a node in maintenance mode in a load balancer only ensures that it doesn’t offer any traffic anymore to the specific server.

Managed availability goes steps further, it can do this because the monitors contain knowledge about the product something load balancers don’t have.

For changing the status of the components on a server you will need to use the Set-ServerComponentState cmdlet. Using this cmdlet with the necessary parameters you can influence the components of a server.

Which components are active on a server depends on which roles are deployed to  server. To find out which components are available on a server you can run Get-ServerComponentState. In the example below you will see an output example of a multi-role Exchange 2013 server:

get-servercomponentstate

As you can see all components are up and running. Let’s assume that we have prepared our AD and are now ready to deploy the bits on our Exchange 2013 servers.

Our environment consists of two Exchange 2013 multirole servers. A third server is used as the File Share Witness (FSW) to maintain quorum.

get-servercomponentstate serverwideoffline

The first step will me to ensure that the transport queues will be empty before continuing the process. Using the Set-ServerComponentState cmdlet we can set the status of a component. Besides the status we will need to provide the requestor. In this case the requestor we are going to use is maintenance.

Set-ServerComponentState –identity ex02 –component –state draining –requestor  maintenanceget-servercomponentstate serverwideoffline

hub_draining

By using the cmdlet above we will put the transport component in draining state. This means it will take care of the messages which are currently in the queue but will not accept any new messages.

You can speed up the process by moving the messages to a transport component hosted on another server. To do this you will need to use the move-messages cmdlet:

Redirect-Messages -server ex02 –targetserver ex01.corp.local

redirect-message

To check if the queues are empty we can use the good old get-queue cmdlet:

Get-Queue –server ex02

queue

If all queues are clean we can continue with disabling all the other components which are active on the server:

Set-ServerComponentState –identity ex02 –component serverwideoffline –state inactive –requestor maintenance

set-servcomponentstat serverwideoffline restore hub

To verify if all components are set to the status inactive we could run the Get-ServerComponentState cmdlet again:

get-servercomponentstate serverwideoffline

Now all components are inactive it’s time to handle the database availability group (DAG) part.

There are a two ways to put a DAG member in maintenance mode. Those who are familiar with Exchange 2010 will remember the start-dagmaintenance script which will help you in putting s DAG member in maintenance model Well good news the script is still available and can be found in the same location as in Exchange 2010, the Exchange scripting directory.

Another method to put  DAG member in maintenance mode is to set the status of the cluster component using the Suspend-ClusterNode, for example:

Suspend-ClusterNode

suspend-clusternode

Once the cluster node has been stopped you will need to prevent the databases from being moved d on the member:

Set-MailboxServer  -Identity ex02-DatabaseCopyActivationDisabledAndMoveNow $trueSet-MailboxServer  -DatabaseCopyAutoActivationPolicy Blocked

set-mailboxserver activation

And as final step we want to set the auto activation policy temporarily to blocked:

Set-MailboxServer  -Identity ex02 -DatabaseCopyAutoActivationPolicy Blocked

Now all prerequired steps have been taken it is time to kick of the setup. In this blog we will use the cmdline to update our Exchange 2013 server. To update the server start the setup using the following parameters:

Setup.exe /m:upgrade /IacceptExchangeServerLicensing

This will start the upgrade to CU2 as you can see below:

setup.exe /m:upgrade

Once the setup has finished you might decide to reboot the server. Once the server is back online it is time to restore the services.

To restore the services we will need need to perform the steps mentioned earlier only then in reverse order.

So we will start with putting the DAG member back online:

First we will make the DAG member and active of part of the cluster again:

Resume-ClusterNode

Once this has been done we need to remove the limits for database failovers which we configured earlier:

Set-MailboxServer  -Identity ex02-DatabaseCopyActivationDisabledAndMoveNow $trueSet-MailboxServer  -DatabaseCopyAutoActivationPolicy Blocked

Set-MailboxServer  -Identity ex02 -DatabaseCopyAutoActivationPolicy Blocked

resume-clusternode

Now our DAG member is back online we need to change the component states to active:

Set-ServerComponentStatus –identity ex02 –component serverwideoffline –status active –requestor maintenance

set-servcomponentstat serverwideoffline restore

When running the Get-ServerComponentStatus cmdlet you will see that the status of the transport component is still draining.

To stop the draining process for the transport component we will need to run the Set-ServerComponentStatus cmdlet again only using a different action parameter:

Set-ServerComponentStatus –identity ex02 –component transport –status active –requestor maintenance

set-servcomponentstat serverwideoffline restore hub

Now when running the Get-ServerComponent cmdlet again the status of each component should show active.

get-servercomponentstate_fullrestore

Here ends the blog about how to install a CU on an Exchange 2013 server. If you hate to type the cmdlets manually then have a look at this script from Michael van Hoorenbeeck:

Micheals script: open

The script will perform the same cmdlets only with less typing for your and will simplify the proces of putting a server in maintenance and restore the services again.

Exchange 2010 SP3 available soon

It looks like we can expect Exchange 2010 SP3 very soon. There are a lot of rumors on going on Twitter and Facebook the Microsoft Downloads already contains the Exchange 2010 SP3 UM Language Pack.

A question by Exchange fan Hakim Taoussi that it has been announced but not available:

 

Hakim_Taoussi

 

Was answered by Bharat Suneja from the MsExchange team with the following tweet:

 

Bharat_Suneja

So for those who have been waiting till they can migrate to Exchange 2013 from Exchange 2010 you should be able soon. If it is wise to do it, well read the several blog posts from Exchange guys and then rethink your decission again.

Let the rollups role

Today it is Microsoft Rollup day. Both for Exchange 2010 SP2 and Exchange 2007 SP3 new rollups have been released. The rollup for Exchange 2010 SP2 contains a lot of fixes. For Exchange 2007 SP3 it is the 10nd rollup which has been released although the fixes contained in the rollup are not as large as for Exchange 2010. The rollup for Exchange 2007 contains a security fix and one issue for a problem with OWA.

An overview of the fixes included on the rollups can be found below:

Exchange 2010 SP2 Rollup 6:

  • 2489941 The “legacyExchangeDN” value is shown in the “From” field instead of the “Simple Display Name” in an email message in an Exchange Server 2010 environment
  • 2717453 You cannot move or delete a folder by using Outlook in online mode in an Exchange Server 2010 environment
  • 2733608 Corrupted Japanese DBCS characters when you send a meeting request or post a reply to a posted item in a public folder in an Exchange Server 2010 environment
  • 2734635 Folder-associated information (FAI) items are deleted when you run the New-InboxRule cmdlet or change Inbox rules in an Exchange Server 2010 environment
  • 2737046 AutoPreview feature does not work when you use Outlook in online mode in an Exchange Server 2010 environment
  • 2741117 High CPU utilization by Microsoft Exchange Replication service on Client Access servers in an Exchange Server 2010 environment
  • 2746030 Incorrect ExternalURL value for EWS is returned by an Exchange Server 2010 Client Access server
  • 2750188 Exchange Service Host service crashes when you start the service on an Exchange 2010 server
  • 2751417 Synchronization fails if you sync an external device to a mailbox through EAS in an Exchange Server 2010 environment
  • 2751581 OAB generation fails with event IDs 9126, 9330, and either 9338 or 9339 in an Exchange Server 2010 environment
  • 2760999 “The signup domain ‘org’ derived from ‘<TenantDomainName>.org’ is not a valid domain” error message when you use the Hybrid Configuration wizard in an Exchange Server
  • 2776259 Msftefd.exe process crashes if an email attachment has an unexpected file name extension or no file name extension in an Exchange Server 2010 environment
  • 2779387 Duplicated email messages are displayed in the Sent Items folder in a EWS-based application that accesses an Exchange Server 2010 Mailbox server
  • 2783586 Name order of a contact is displayed incorrectly after you edit the contact in an Exchange Server 2010 environment
  • 2783631 User-Agent field is empty when you run the Get-ActiveSyncDeviceStatistics cmdlet in an Exchange Server 2010 SP2 environment
  • 2783633 You cannot move or delete an email message that is larger than the maximum receive or send size in an Exchange Server 2010 environment
  • 2783649 Private appointment is visible to a delegate in an Exchange Server 2010 environment
  • 2783771 Mailbox on a mobile device is not updated when EAS is configured in an Exchange Server 2010 environment
  • 2783772 Edgetransport.exe process crashes after a journal recipient receives an NDR message in an Exchange Server 2010 environment
  • 2783776 You cannot perform a cross-premises search in a mailbox in an Exchange Server 2010 hybrid environment
  • 2783782 Error message when you use Scanpst.exe on a .pst file in an Exchange Server 2010 environment
  • 2784081 Store.exe process crashes if you add certain registry keys to an Exchange Server 2010 Mailbox server
  • 2784083 Week numbers in the Outlook Web App and Outlook calendars are mismatched in an Exchange Server 2010 environment
  • 2784093 SCOM alerts and event ID 4 in an Exchange Server 2010 SP2 organization that has Update Rollup 1 or later
  • 2784566 Exchange RPC Client Access service crashes on an Exchange Server 2010 Mailbox server
  • 2787023 Exchange Mailbox Assistants service crashes when you try to change a recurring calendar item or publish free/busy data in an Exchange Server 2010 environment
  • 2793274 A new option is available that disables the PermanentlyDelete retention action in an Exchange Server 2010 organization
  • 2793278 You cannot use the search function to search for mailbox items in an Exchange Server 2010 environment
  • 2793279 Exchange Server 2010 does not restart when the Microsoft Exchange Replication service freezes
  • 2793488 Internet Explorer freezes when you connect to the OWA several times in an Exchange Server 2010 environment
  • 2810616 Email message delivery is delayed on a Blackberry mobile device after you install Update Rollup 4 for Exchange Server 2010 SP2

download

Exchange 2007 SP3 Rollup 

2783779 A hidden user is still displayed in the Organization information of Address Book in OWA in an Exchange Server 2007 environment

download

Microsoft release Exchange 2010 SP2 Rollup 5

Microsoft has release Rollup 5 for Exchange 2010 SP2 yesterday. This rollup contains fixes for the following issues:

  • 2275156
    The inline contents disposition is removed when you send a “Content-Disposition: inline” email message by using EWS in an Exchange Server 2010 environment
  • 2499044
    You cannot save attachments in an email message by using OWA if the subject line contains special characters in an Exchange Server 2010 environment
  • 2509306 

    Journal reports are expired or lost when the Microsoft Exchange Transport service is restarted in an Exchange Server 2010 environment

  • 2514766A RBAC role assignee can unexpectedly run the Add-ADPermission command on an Exchange Server 2010 server that is outside the role assignment scope
  • 2529715Slow network or replication issues after you change the number of virus scanning API threads in Microsoft Exchange Server 2010
  • 2536704
    Mailbox users who are migrated by using ILM 2007 cannot use the Options menu in OWA in an Exchange Server 2010 environment
  • 2537094French translation errors occur when you edit a response to a meeting request by using OWA in an Exchange Server 2010 SP1 environment
  • 2555800 

    You cannot use the GetItem operation in EWS to retrieve properties of an email message in an Exchange Server 2010 environment

  • 2555850
    You cannot delete a mailbox folder that starts with a special character in its name by using Outlook in an Exchange Server 2010 environment
  • 2556096
    The columns in the .csv logging file are not lined up correctly when you perform a discovery search on a mailbox in an Exchange Server 2010 environment
  • 2556107
    The columns in the .csv logging file are not lined up correctly when you perform a discovery search on a mailbox in an Exchange Server 2010 environment
  • 2556133
    A device that uses Exchange ActiveSync cannot access mailboxes in an Exchange Server 2010 environment
  • 2556156
    Extra.exe crashes when it performs RPC activity checks against an Exchange Server 2010 server
  • 2556352
    “ChangeKey is required for this operation” error message in Outlook for Mac 2011 in an Exchange Server 2010 environment
  • 2556407
    Certain client-only message rules do not take effect on email messages that are saved as drafts in an Exchange Server 2010 environment
  • 2559926
    “There are no items to show in this view.” error message when you try to view a folder by using Outlook in an Exchange Server 2010 environment
  • 2572958
    The “Test-OutlookConnectivity -Protocol HTTP” command fails with an HTTP 401 error in an Exchange Server 2010 environment

The rollup can be downloaded via the site below:

download

Microsoft has just released version 2 of the latest Exchange 2010 SP1 and SP2 rollups. At this moment you can’t find a lot of information about it. The only reference which can be found on the dowload pages of both rollups is a reference to security bulletin MS12-058. In this security bulletin an issue is described about a vulnerability in the Web Ready Document Viewing functionality of Exchange 2010 in the Oracle Outside In Libraries

The updates can be downloaded via the links below:

Exchange 2010 SP1 Rollup 7 v2: http://www.microsoft.com/en-us/download/details.aspx?id=34957

Exchange 2010 SP2 Rollup 4 v2: http://www.microsoft.com/en-us/download/details.aspx?id=34956

More information about the vulnerability can be found on the page below:

Security Bulletin MS12-058: http://technet.microsoft.com/en-us/security/Bulletin/MS12-058

Update: this updates rollup has been released because of the expiration of the signatures which are used to sign the code. The advice is to install the v2 of the rollup despite it was already a part of the v1 of this update.

The risks of publishing EWS

update 4-3: changed a parameter because it was incorrect

Starting from Exchange 2007 several functionalities are offered via web services also known as Exchange Web Services (EWS). Functionalities offered by EWS are for example free/busy and Out Of Office.

Several clients can benefit from EWS among them Outlook 2007 and higher, Entourage with EWS extension and Outlook 2011. The last two clients are only available for Mac and don’t use MAPI to send/receive e-mail but do use EWS to do this. Another Mac related product is Apple Mail which works the same as Entourage and Outlook 2011.

On your local network this will not be the issue in most cases but if you are publishing your Exchange environment to the internet you might see some unwanted traffic. The reason why? Well if you are publishing EWS with the default authentication methods users can login using their username and password. Let’s give a short example:

Your company only wants to allow users to use ActiveSync and OWA for e-mail access. Outlook Anywhere is not enabled since you only allow full Outlook access when users are connected via VPN.

Now comes the fun when using Entourage, Outlook 2011 or Apple Mail your users will be able to send/receive their mail. This because they are using EWS and EWS is published either directly or more secure via a reverse proxy. This because you can use to reverse proxy to prevent the publishing of EWS. Although this may not be an option as we will see later in this blog.

How to solve this? Well it depends if you are not having Entourage and Outlook 2011 client on your local network you can choose to block both clients.

To configure this on your Exchange server run the following cmdlet:

Set-OrganizationConfig –EWSAllowEntourage $false –EWSAllowMacOutlook $false –EWSAllowApplicationAccessPolicy: EnforceAllowList

Let’s explain the parameters used:

  • EWSAllowEntourage: specifies if Entourage is allowed or not
  • EWSAllowMacOutlook: specifies if Outlook 2011  is allowed or not
  • EWSAllowApplicationAccessPolicy: specifies if other applications are allowed to use EWS by using either allow (EnForceAllowList) or block (EnForceBlockList) specific applications/services

The last parameter is a little bit tricky since this will also block other applications/services that want to use EWS. This due to the fact that we not used the AllowList parameter.  A few examples of these applications/services are: OCS/Lync clients and BlackBerry Server.

To allow those applications we will need to find out which client is trying to connect EWS does use the user agent string. The user string can be found by searching in the IIS log for example:

2012-08-03 12:07:40 192.168.1.2 POST /EWS/Exchange.asmx – 443 – 192.168.1.10 Microsoft+Office/12.0+(Windows+NT+5.1;+Microsoft+Office+Outlook+12.0.6425;+Pro)

2012-08-03 00:03:14 192.168.1.2 GET /autodiscover/autodiscover.xml – 443– 192.168.1.10 OC/4.0.7577.4051+(Microsoft+Lync+2010) 200 0 0 0

Below a list of user agent strings used by some popular programs:

  • BlackBerry Servers: Mozilla/4.0+
  • Microsoft OCS 2007 R2: OC/3.5.*.*
  • Microsoft Lync 2010: OC/4.*.*.*
  • Microsoft Lync Web App: CWA/4.*.*.*
  • Microsoft Lync Phone Edition: OCPhone/4.*.*.*

Let’s change the earlier scenario a little bit:

Your company only wants to allow users to use ActiveSync and OWA for e-mail access. Outlook Anywhere is not enabled since you only allow full Outlook access when users are connected via VPN. The company decides to implement Microsoft Lync 2010 and wants to use all options including the Outlook integration options. Lync is allowed to be used without setting up a VPN connection.

 

In this case we will need to exclude the Lync 2010 client from being blocked if it tries to use EWS:

Set-OrganizationConfig –EWSAllowEntourage $false –EWSAllowMacOutlook $false –EWSApplicationAccessPolicy: EnforceAllowList –AllowList {“*OC*”}

By using the above cmdlet we will only allow the OCS 2007 R2 and Lync 2010 client to use the EWS functionality.

Another way to block the EWS access is using your F5 appliance, if you have one of course. A good description on how to configure your F5 to support this can be found here written by fellow MVP Tom Pacyk.

Provisioning mailbox rules

You may not see it in every organization but in a lot of organizations Outlook rules are used to automate some tasks such as: moving item to another folder, auto reply on messages, etc.

In this blog we will have a look at how to provision Outlook rules for a user so they won’t have to create them. But first have a look at the rules. As you may know you can configure both server and client side rules in Outlook. But what’s the difference between them?

  • Server side rules: are executed at the server side and so they are always running;
  • Client side rules: are execute at the client side and will only work when Outlook or OWA is running;

Most of the rules you can configure are client side rules and only a few of them are server side rules. One example of a server side rule is auto replying with a message on a new arrived e-mail.

To provision Outlook rules you can use the New-InboxRule cmdlet this cmdlet will give you the ability to create inbox rules for every user. So let’s have a look at an example.

New-InboxRule ‘Spam Summary’ -Mailbox johan -From antispam@domain.com -SubjectContainsWord “Spam Summary“ -MoveToFolder ’ johan:\ Spam Summary’

The rule above will be applied to all messages which are sent to my mailbox and are sent from antispam@domain.com and have as subject Spam Summary. The rule will move the specific message to the folder Spam Summary. One remark must be made about the folder. The folder must exist if not you will get a warning.

So wouldn’t it be nice to automate the complete process when a new mailbox is created? If this is what you want cmdlet extensions are the answer. With cmdlet extensions you can extend cmdlets by executing additional cmdlets after the first cmdlet has been executed.

In this example we would only like to create the new folder and the Outlook rule after a new mailbox is created. So the cmdlet which needs to be extended is New-Mailbox.

The first step in the process will be to modify the ScriptingAgentConfig.xml.sample. This file can be found here: \V14\Bin\CmdletExtensionAgents. First make a backup of the original XML before making any changes. Once the backup is rename the file and remove the .sample extension and open it in an editor, for example Notepad.

if($succeeded) {
$newmailbox = $provisioningHandler.UserSpecifiedParameters[“Name”]
$newfolder= $newmailbox + :\Spam Summary
New-MailboxFolder -Parent $newmailbox -Name Spam Summary
New-InboxRule ’Spam Summary’ -Mailbox $newmailbox -From antispam@domain.com -
SubjectContainsWord ’Spam Summary’ -MoveToFolder $newfolder }

We are using two parameters:

  • $newmailbox: contains the name of the created mailbox
  • $newfolder: the name of the folder we want to create in the mailbox

After the parameters have been defined we will first create the new folder using the New-MailboxFolder cmdlet and then use create the new rule using New-InboxRule cmdlet.

Now save this file and copy it to each Exchange server in your environment. The next step is to enable the scripting agent. If you don’t do it the script simply won’t be executed.

To enable the scripting agent open the Exchange Management Shell (EMS) and run the following cmdlet:

Enable-CmdletExtensionAgent “Scripting Agent”

Repeat this step on every Exchange server in your environment.

Now we configured everything it’s time to see if it really works. Create a new mailbox via either the Exchange Management Console or Shell. After the mailbox is created verify if a new folder and rule are created successfully by logging into OWA or by using Outlook.

So let’s verify if it really works. In this example we just created a user called provisioned_user:

new-mailbox -name provisioned_user -alias provisioned_user -UserPrincipalName provisioned_user@corp.local

When running the cmdlet with the –verbose parameter you will see that the Cmdlet Extension Agent is executed after the mailbox has been created:

Now the mailbox has been created let’s verify if the new folder and inbox rule have been created. We will use OWA to verify if both have been created. When logging in to OWA you will see that the folder has been created:

When opening the Exchange Control Panel (ECP) and select the Organize E-mail option in the left menu you will see that an inbox rule has been created:

So as you can see you can provision the anti-spam folder and rule for new mailboxes using the cmdlet extensions. Besides doing this kind of things several other options can be configured using this option. Some examples are:

  • Disable POP3
  • Disable IMAP
  • Set the Regional Configuration/Language

For more information you can have a look at the following pages:

  • Using Cmdlet Extension Agents to cause automatic events to occur in Exchange 2010 – life just got simpler!: open
  • Cmdlet Extension Agents Part 1: Automatic archive creation: open