Log in



Archive for October, 2009

Error installing Client Access Server role in Exchange 2010

October 27th, 2009 by Scott

I was in the process of installing Exchange 2010 today on a W2K8 box when I came across the error: 

The start mode for the Net. TCP Port Sharing service must be set to Automatic before Setup can continue

As it turns out the Net. TCP Port Sharing Service is set to a manual start up

 

The best way to resolve this is to set the Startup type as Automatic.  You can do this in two ways, one by opening the properties of the service and selecting Automatic or by opening up PowerShell (Which you should have installed prior to deploying Exchange) and typing the command Set-Service NetTcpPortSharing –StartupType Automatic.  Walla!  The service is now configured correctly and you may continue with the Exchange 2010 install. 

*Note: This was deploying Exchange 2010 RC1, this may change with the RTM release.

Sizing Exchange 2010 Client Access Servers

October 26th, 2009 by Scott

 

I was reading through technet today to review some of the new features of Exchange 2010 and came across an interesting little note about Sizing for Client Access Servers.  In Exchange 2007 it was recommended to size a server of 1GB per core on the Client Access Server.  Well, reading here I noticed that it states for a large organization that you should consider doing 2GB per core with a Max of 8GBs.  A typical installation is recommended to have 4GB of RAM.  However, based on your deployment you may need to add additional servers to your environment depending on just how large.  MS is also recommending 1:4 Core ratio for CAS to Mailbox.  That is for every four cores on a MB server you should have 1 core for your CAS.  For example, if you deploy eight Mailbox servers in an Active Directory site, and each Mailbox server contains four processor cores (for a total of 32 Mailbox server processor cores), you should deploy at least eight Client Access server processor cores. These could be deployed as two Client Access servers with four processor cores each, or four Client Access servers, with two processor cores each.

Another interesting aspect is that Clients will now connect to the Client Access Servers for all access, this includes Outlook 2007/2010 as well as Outlook Web App.  This works rather slick when using DAGs and moving a users mailbox.  Since the user is connected to the CAS they will not see an outage, but rather the CAS will point them to the new mailbox server on the backend.  Having considered that all clients will connect to the CAS it may be recommended for additional memory on the server itself, if you’ have a large environment or perhaps you happen to have a CAS and HUB installed on one box. 

Time will tell as Exchange 2010 gets out in the world.  Much of the information is based on RC1 and Beta so who knows, it will probably change.  I do recall reading an article some time ago that a CAS should have no less then 16GBs or RAM. 

MS does have a good table for helping on sizing an Exchange 2010 Client Access Server.  To be honest given the fact that Exchange 2010 is supported for virtualization how hard will it be to adjust settings?

Check out Recommended Performance Counters, it’s at the bottom of the page.

PS3 will soon support Netflix!

October 26th, 2009 by Scott

I just came across this article: http://www.engadget.com/2009/10/26/netflix-coming-to-playstation-3/ that mentions the PS3 will support Netflix!  Can we say Sweet?  Considering I have a PS3 which I use for Blu-ray movies and some games this really adds to the mix!  I must admit I am quite happy to hear this.

Now, if only the XBox 360 would include a blu-ray player built in, I’ve heard rumors but nothing Solid. 

Autodiscover for ActiveSync!

October 25th, 2009 by Scott

Microsoft has introduced a new feature in Exchange 2010, autodiscover for mobile devices.  The idea here is that a user will enter their email address and their password.  The mobile will then query a DNS server looking for autodiscover.domain.com and grab an xml file from the web server.  The xml file will then configure the device for the user!  This communication is over SSL so it is secure.  Talk about making the deployment of mobiles even easier!  Of course the mobile device needs to be able to support audodiscover.

Client Access Servers in the DMZ

October 21st, 2009 by Scott

I came across an interesting article over at the Exchange Team blog, http://msexchangeteam.com/archive/2009/10/21/452929.aspx.  Basically explaining why not to place a CAS in the DMZ. 

I have to agree, I have come across this request a number of times in the past while at client sites stating that they would like to place a CAS in the DMZ and I have always recommended (even when the subject doesn’t come up) to place an ISA server in the DMZ to act as a reverse proxy.  ISA 2006 really gives you added benefit protecting your servers from a number of different attacks.  By allowing users to authenticate at the ISA level in the DMZ your remove the opportunity for a malicious user to attack your servers.  There is also the aspect that you can use ISA to load balance and perform link translation, that’s where your internal link is different than your external link. 

The other added benefit?  You don’t have to open your internal firewall to all the required ports Exchange will use.  This would be termed swiss cheese. 

So, if you’re thinking about placing a Client Access Server in the DMZ think twice, you really shouldn’t.

Thanks to the MS Exchange team for posting a reminder out there!

Network Load Balancing recommended for Exchange 2010 CAS public facing (internet facing) and internal

October 21st, 2009 by Scott

I was reading an interesting note on the Client Access Server role in Exchange 2010 and ActiveSync.  When ActiveSync connects to a CAS it will constantly use that same connection for receiving emails and communication.  What occurs in the event the CAS server goes off line?  The Mobile device will continue to try to connect to that same server.  This means that if you have an outage for an extended period of time users will not be able to receive email on their mobile.   In order to resolve this issue Microsoft recommends to NLB the Client Access Servers both internally and externally (internet facing).  When a device is proxied to the proper CAS it will maintain that connection.  If you point the URL/IP to a NLB device the mobile will use the NLB information rather than the server information.  What this means then is that when a CAS is off line that is behind a NLB device users will use the NLB information and connect to the remaining server rather than trying to connect to the down server. 

MS Provided a nice diagram of Proxying for NLB CAS:

In an organization that has multiple Active Directory sites and multiple Client Access servers in each site, you can use Network Load Balancing (NLB) to optimize traffic among the Client Access servers in each site. We recommend that you include only Client Access servers within the same Active Directory site in a load-balancing array. You can deploy NLB in an Internet-facing Active Directory site and in a non-Internet-facing Active Directory site. The following figure shows two Active Directory sites that implement NLB.

 

As a note it appears that the Hub Transport Server in 2010 is not supported for NLB:  “In many deployments, the installation of the Client Access server role and the Hub Transport server role are on the same computer. In this topology, you can configure NLB for the Client Access server role separately from the Hub Transport server role. Currently NLB isn’t supported on the Hub Transport server role. However, it’s supported for the Client Access server role.”

More info:  http://technet.microsoft.com/en-us/library/bb310763(EXCHG.140).aspx

Exchange 2010 Client Access Server Proxying…

October 20th, 2009 by Scott

I came across an interesting note on the Exchange 2010 ActiveSync and Exchange 2003

Users who have mailboxes on an Exchange 2003 server who try to use Exchange ActiveSync through an Exchange 2010 Client Access server will receive an error and be unable to synchronize unless Integrated Windows authentication is enabled on the Microsoft-Server-ActiveSync virtual directory on the Exchange 2003 server. This enables the Exchange 2010 Client Access server and the Exchange 2003 back-end server to communicate using Kerberos authentication.

 Proxying isn’t supported between virtual directories that use Basic authentication. For client communications to be proxied between virtual directories on different servers, the virtual directories must use Integrated Windows authentication. 

 http://technet.microsoft.com/en-us/library/bb310763(EXCHG.140).aspx

Exchange 2010 new feature of Hub Transport and the Transport Dumpster

October 19th, 2009 by Scott

In Exchange 2007 a new role was deployed called the Hub Transport Server, to make a long story short the Hub Transport Server was responsible for routing all emails inside and outside of an organization.  For redundancy purposes the Hub Transport Server has a feature called the Transport Dumpster.  The Transport Dumpster was responsible for keeping a record of emails which passed through the Hub Transport until the size or time limit was exceeded which was specified by the administrator, in which case they would be removed from the queue.   The Transport Dumpster was only used for redundant solutions such as a CCR deployment.  In the event of a failure the CCR passive node would query the Transport Dumpster to validate that all emails in the database were valid and up to date.

The function of the Transport Dumpster has changed in Exchange 2010.  When using DAGs the transport dumpster now receives feedback from the replication pipeline to determine which messages have been delivered and replicated. As a message goes through Hub Transport Servers on its way to a replicated mailbox database in a DAG, a copy is kept in the transport queue until the replication pipeline has notified the Hub Transport server that the transaction logs representing the message have been successfully replicated to and inspected by all copies of the mailbox database. Once the logs have been replicated to and inspected by all database copies, they are truncated from the transport dumpster. This keeps the transport dumpster queue leaner by maintaining only copies of messages whose transactions logs have not yet been replicated.

I was able to find out this information and more at: http://technet.microsoft.com/en-us/library/dd638137(EXCHG.140).aspx

SAV > Exchange

October 18th, 2009 by Scott

So, I had an issue yesterday where an Exchange server just stopped working. No reason at all. I was looking through the net and came across a number of articles but NOTHING related or resolved my problem.

I had a lot of errors in my event logs related to Event ID 2114 from the MSExchange ADAccess. The Exchange server was not able to locate any of the Domain Controllers, which was odd because the topology service was able to locate the domain controllers.

Well, after some time I decided to disable the AV software on the server and boom, communication restored and the Information Store Service was able to start allowing the mail databases to be mounted.

It looks like an update came down in the last day or so which was preventing communication to the DCs. How weird is that? Now I’m going to have to look at AV policies to figure out how to prevent this in the future. And yes, exceptions are configured.   I’m betting network protection but odd that this thing was running great for some time and just STOPPED!

Microsoft Office Communicator cannot Sync Address book

October 16th, 2009 by Scott

I recently deployed OCS 2007 R2 for a client that involved a front end server and a edge sync server. A few days after deploying OCS we noticed that MOC had an error “Cannot synchronize with the corporate address book. This may be because the proxy server settings in your web browser does not allow access to the address book. If the problem persists, contact your system administration” Upon doing some investigation I noticed an error in the event logs, Event ID: 5021 Source WAS. The error was “The identity of application pool LSGroupExpAppPool is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights. If the identity is not corrected, the application pool will be disabled when the application pool receives its first request. If batch logon rights are causing the problem, the identity in the IIS configuration store must be changed after rights have been granted before Windows Process Activation Service (WAS) can retry the logon. If the identity remains invalid after the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number.” Upon checking the batch logon rights under Security Settings> Local Policies>User Right Assignment I noticed that the service account was not permitted. This was a result of Group Policy over-writing the local security policy and in essence disabling the application pool.

The fix? We had to add the service account to the GPO, did a gpupdate /force and then restarted MOC. All is well again!