|
|
Monday, August 15, 2011
Several Outlook 2010 users with Exchange 2010 mailboxes reported the following issues.
When creating a new message and adding a Universal distribution list to the To: field, they attempt to expand the membership of the DL and they get an “Cannot perform the requested operation. The command selected is not valid for the recipient. The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action.” error message.
In addition, if they tried to look at the Organization properties of the user, it appears blank and they get an “Unable to connect to retrieve additional data” error as shown below.
While we were troubleshooting the issues, we checked the status of the Microsoft Exchange Address Book services on all of our CAS servers. On one of our CAS servers, we found a problem with the Microsoft Exchange Address Book service. All of the other Microsoft Exchange services on the server were fine. After restarting the Microsoft Exchange Address Book service on the CAS server, users were able to successfully expand the membership of a DL and view Organization information.
Tuesday, August 09, 2011
Recently, my Active Directory user account was getting locked out on a regular basis after changing my user account password. In our environment, the most two common causes for Active Directory user account lockouts are disconnected RDP sessions or an invalid password on a mobile device configured for Exchange ActiveSync access.
I used the LockoutStatus.exe Tool to search for one or more disconnected RDP sessions using my old password but I was not able to find anything. So, the next thing I checked was my iPhone. I checked my iPhone Exchange account settings and password and confirmed everything checked out and my device was synchronizing mail just fine.
After several hours of additional troubleshooting, I learned that it was an older mobile device, a Pocket PC, that I own that was causing my user account to lockout. To make a long story short, I needed to charge up the battery for my Pocket PC device for another project I was working on and I had forgotten that I had previously configured the device for Exchange ActiveSync access quite some time ago and didn’t even think about it while I was charging up the battery. After taking care of my Pocket PC device, my Active Directory user account was no longer getting locked out.
Here are a couple of troubleshooting tips to help you narrow down your search if you run into something similar in your environment.
1) On a CAS Server, run the PowerShell command: Get-ActiveSyncDevice –Mailbox <user’s email address> to get a list of user devices
2) On a CAS Server, run the PowerShell command: Get-ActiveSyncDeviceStatistics –Mailbox <user’s email address> to get the LastSync information for the each of the devices the user owns
3) Search through the IIS logs on all of your CAS servers. You can search for iPhone or, in my case, PocketPC entries in the logs on each of the CAS servers to help narrow down your search.
Recently, several enabled Remote call control (RCC) users reported that they were having issues making phone calls from Communicator.
When they attempted to call a number, they got a “Cannot locate <user>” error message and when they clicked on Retry, they got another error message, “There may be an error in the address. Check the address and then try again.”
After some troubleshooting, we found out our CSTA Gateway server was using an expired certificate.
For communication to take place, the CSTA Gateway and Microsoft Office Communications Server 2007 R2 must exchange signed server certificates each time a TLS session is opened.
After installing a valid certificate and restarting the services on the CSTA Gateway server, our users were able to make phone calls from Communicator again.
Thursday, May 26, 2011
When we originally deployed OCS 2007 R2 in our environment, we only built one OCS 2007 R2 Access Edge Server. So, recently, we built three more OCS 2007 R2 Access Edge Servers for high availability and additional capacity purposes.
To load-balance all of our Access Edge Servers, we use a hardware load-balancer. Please note a load balancer is required for arrays of OCS 2007 R2 Access Edge Servers. For more information about load balancers for OCS 2007 R2, please click here.
Here are a few things we learned.
1) When you configure the Edge Servers tab under Global Properties, it is important that you add both the FQDN of the array name used to load-balance all of your Access Edge Servers and the FQDN of each of your Access Edge Servers. If you do not add the array and server names, you will have problems sending out outbound IM messages and seeing Presence information.
2) When you configure the Federation tab under Global Properties, make sure you specify the FQDN of the array name to successfully load-balance outbound IM traffic from the pool to the Access Edge Servers. Do not specify the FQDN name of an Access Edge Server.
3) When you build a new Access Edge Server, check and make sure the public CA certificate you are using for the external interface is able access the URL for the CRL (certificate revocation list) through firewall port 80. For more information, check out a previous blog posting.
4) In addition to firewall port 80, check and make sure firewall port 5061 is open from the new Access Edge Servers to each of the Public IM providers to ensure outbound IM traffic works from the Access Edge Server external interfaces to the Public IM servers.
5) When you build a new Access Edge Server, check and make sure that you have the AOL Root Certificate installed in your Root Certificate store. If you do not have the AOL Root Certificate installed, you will not be able to see Presence information for your AOL contacts in Communicator.
Wednesday, May 25, 2011
After you install and configure Microsoft Forefront Protection 2010 for Exchange on your Exchange 2010 Hub Transport Servers, you can use the Exchange PowerShell Send-MailMessage cmdlet to test your Forefront configuration on one or more Hub Transport Servers without having to stop the Microsoft Exchange Transport service. Also, you can use the PowerShell cmdlet to test your file filters using different types of e-mail attachments to ensure Forefront is working as designed.
Here are a couple of examples for your review.
Test a Forefront Sender-Domain filter
[PS] C:\> Send-MailMessage –From Sender@domainName.com –To Receiver@domainName.com –Subject “Test Sender-Domain filter” –Body “This is a test message” –SmtpServer <insert name of your Hub Server you want to test>
Test a Forefront File Extension Name filter
[PS] C:\> Send-MailMessage –From Sender@domainName.com –To Receiver@domainName.com –Subject “Test File Extension Name filter” –Body “This is a test message” –Attachments C:\Forefront\filename.exe –SmtpServer <insert name of your Hub Server you want to test>
Tuesday, May 10, 2011
When we started our Exchange 2010 deployment, we ran into an issue with not being able to modify distribution lists. I documented how to fix this issue in a previous post.
Not too long ago, we started getting a few reports from users with Exchange 2010 mailboxes that they could not modify their distribution lists and the error message they were getting was the same error message we saw when we started deploying Exchange 2010. When an user attempted to modify a distribution list they owned, they would get a “Changes to the distribution list membership cannot be saved. You do not have sufficient permission to perform this operation on this object.” error message.
After we confirmed that no one made any changes to the RBAC role outlined in Matt Byrd’s article, we started troubleshooting the problem. Shortly thereafter, we noticed that when we tried to view the properties of the distribution lists users were having trouble modifying using the Exchange Management Console, we would get a properties on this object have invalid data error message.
After acknowledging the error message above, we would get a some controls are not valid error message. It would state either the property value is invalid or the property expression isn’t valid.
After we removed a trailing space from a DL Display name, removed two brackets () from a DL Alias name, and removed one or more spaces from a DL Alias name and waited for Active Directory replication to complete, users were able to modify their distribution lists successfully.
So, if you have users with problems modifying their distribution lists in your environment, review their distribution lists, especially the Display name and/or Alias name, and make sure their distribution lists are not using unsupported characters.
Tuesday, April 12, 2011
If you provide external access to Microsoft Office 2007 R2 Communicator Web Access Server for your users, you need to make sure your users are enabled for remote user access.
If your users are not enabled for remote user access and they attempt to access OCS 2007 R2 externally, they will get an “Cannot sign in because your user account does not permit external access to Microsoft Office Communicator Web Access server. Contact your system administrator.” error message.
Saturday, March 26, 2011
We noticed some very odd, random behavior in our environment specifically with Exchange 2010 ActiveSync and Outlook Web App.
Some of our mobile devices had trouble synchronizing email (problems with connecting, direct push wasn’t working properly). Some of our users had trouble connecting to Outlook Web App. Some of our users using Outlook Web App externally were inadvertently connecting to other user mailboxes that they did not have permission to and, not to mention, a serious security breach (I didn’t think it was possible but I saw it with my own eyes).
In addition, I noticed that we were having intermittent problems connecting to our external Office Communications 2007 Server web portal.
We spent a significant amount of time troubleshooting our Exchange 2010 environment and we could not find any Exchange infrastructure issues that were contributing to the issues above. Also, we could not find any problems with Exchange 2010 ActiveSync and Outlook Web App.
These issues were happening very randomly which made it very difficult to troubleshoot. However, there was one common denominator. The ISA 2004 Servers.
The first thing we did was to start capturing some logging data on the ISA Servers. Shortly thereafter, we noticed some connection failures in the logs from a F5 floating IP address as we use F5 devices to load-balance external traffic (ActiveSync/OWA) to our ISA 2004 Servers. So, we contacted our F5 engineers and asked them to start capturing some data on the F5 devices. They were able to determine quickly that they were seeing quite a few number of connection refused or failures along with many successful connections to our ISA Servers in their logs. Using this information, we started researching connection limits on an ISA 2004 Server.
There is a very good TechNet article, Deployment Recommendations for Connection Limits in ISA Server 2004, that explains in detail how to configure connection limits for ISA 2004.
After reading the article, we modified the Connection limit per client from 160 to 400 on all of our ISA Servers following the steps under Appendix A: Configuring Connection Limits in the article.
We noticed a somewhat small improvement after making the change but some users were still reporting issues. After some more research, we created a new entry for our F5 floating IP address on the ISA Servers and added it to the Custom connection limit as shown below.
After we made the change, we no longer had any more issues including the security breach issue with accessing another person’s mailbox. Something to keep in mind if you use one or more ISA 2004 Servers in your Exchange 2010 environment and your environment grows over time.
In case, anyone was wondering, we have plans to upgrade to Microsoft Forefront Threat Management Gateway later this year :-)
Thursday, March 24, 2011
Tuesday, March 15, 2011
|