A UC Guru Who Loves To Share -- Alan Wang's Blog
Thursday, October 20, 2011
Toggle between Windows 8 Metro Start Screen and Classic Windows 7 Start Menu
My first app on Windows 8 Developer Preview is something called Windows 8 Start Menu Toggle, which enables you toggle between the Metro Start screen and Classic Windows 7 start menu by one click. Highly recommend and you can find the download here.
Monday, October 3, 2011
Jetstress 2010 Test Result Evaluation
In this blog, I am going to talk about how to evaluate your JetStress test. You can find the instruction on how to install, configure, and run JetStree in this blog.
The following criterion should be evaluated for each test run.
You can find Total Database Required IOPS under Role Requirement worksheet in the Mailbox Role Calculator.
This value is calculated by the Mailbox Role Calculator using multiple input factors. Below are some of the key factors that determine the value:
You can use Thread Count to achieve the target Achieved Transactional I/O per Second. Basically the bigger Thread Count is, the higher the Achieved Transactional I/O per Second will be achieved.
The first time you runt the test, you would leave everything as default (Thread Count = 1), you then compare the value to determine whether you should increase Thread Count or not. For example, assume Total Database Required IOPS / Server predicted in the Mailbox Role Calculator is 500. Your first test result looks like below:
The test result will show Succeeded. But you know it is not because it doesn't achieve the target value which is 700 predicted by the Mailbox Role Calculator. Next you want to increase the Threat Count to achieve more IOPS. Now the question is what Thread Count should I use? Below is a table taken from a single database running on a RAID10 LUN with 24x2.5" 10K SAS HDD's.
I would recommend you increase the Thread Count to bigger value to find out where the result should fail. For example, I increased the Thread Count to 5 and received the following result:
Now I've achieved the target IOPS of 800 which is higher than 700 predicted by Mailbox Role Calculator. Unfortunately, the test failed at both I/O Database Reads Average Latency and I/O Log Writes Average Latency. So I know my existing storage solution will not support a total IOPS on any server that is over 800.
Next I dropped the Thread Count to 3 and my result reads as below:
I am very happy with the result as it shows my storage will support IOPS/server up to 730 which is higher than what is predicted by the Mailbox Role Calculator, while I/O Database Reads Average Latency and I/O Log Writes Average Latency are also below minimum.
In a real world, you don't have to run multiple tests. As long as you get one result that meet all three criterion you are certain the storage meets the requirement. But if you want to find out the maximum it can support up to, you will have to get a failure test.
If it is not possible to achieve the right IOPS value by modifying the thread count it becomes necessary to modify the Sluggishsessions value within the JetStressConfig.xml file. The Sluggishsessions value adds a pause between each task. This allows a level of fine-tuning over the workload dispatched by JetStress. As Sluggishsessions is increased the achieved IOPS value decreases. To change the value, open the JetStressConfig.xml file and look for the default configuration option
<SluggishSessions>1</SluggishSessions>
Modify the value, save the configuration file and then re-start JetStress.
Use the table below as a guide to determine what to do next after each test till you get a satisfying result.
The following criterion should be evaluated for each test run.
- DB IOPS Target: Is the Achieved Transactional I/O per Second in the test report higher than the Total Database Required IOPS / Server predicted in the Mailbox Role Calculator.
- Is the I/O Database Reads Average Latency in the test report < 20ms?
- Is the I/O Log Writes Average Latency in the test report < 10ms?
You can find Total Database Required IOPS under Role Requirement worksheet in the Mailbox Role Calculator.
This value is calculated by the Mailbox Role Calculator using multiple input factors. Below are some of the key factors that determine the value:
- Total Number of Tier-X user Mailboxes / Environment
- Total Send /Receive Capability / Mailbox / Day
- Number of database / Server
You can use Thread Count to achieve the target Achieved Transactional I/O per Second. Basically the bigger Thread Count is, the higher the Achieved Transactional I/O per Second will be achieved.
The first time you runt the test, you would leave everything as default (Thread Count = 1), you then compare the value to determine whether you should increase Thread Count or not. For example, assume Total Database Required IOPS / Server predicted in the Mailbox Role Calculator is 500. Your first test result looks like below:
Achieved Transactional I/O per Second | 500 |
I/O Database Reads Average Latency | 8 |
I/O Log Writes Average Latency | 0.2 |
The test result will show Succeeded. But you know it is not because it doesn't achieve the target value which is 700 predicted by the Mailbox Role Calculator. Next you want to increase the Threat Count to achieve more IOPS. Now the question is what Thread Count should I use? Below is a table taken from a single database running on a RAID10 LUN with 24x2.5" 10K SAS HDD's.
I would recommend you increase the Thread Count to bigger value to find out where the result should fail. For example, I increased the Thread Count to 5 and received the following result:
Achieved Transactional I/O per Second | 800 |
I/O Database Reads Average Latency | 26 |
I/O Log Writes Average Latency | 4.7 |
Now I've achieved the target IOPS of 800 which is higher than 700 predicted by Mailbox Role Calculator. Unfortunately, the test failed at both I/O Database Reads Average Latency and I/O Log Writes Average Latency. So I know my existing storage solution will not support a total IOPS on any server that is over 800.
Next I dropped the Thread Count to 3 and my result reads as below:
Achieved Transactional I/O per Second | 730 |
I/O Database Reads Average Latency | 17 |
I/O Log Writes Average Latency | 3.2 |
I am very happy with the result as it shows my storage will support IOPS/server up to 730 which is higher than what is predicted by the Mailbox Role Calculator, while I/O Database Reads Average Latency and I/O Log Writes Average Latency are also below minimum.
In a real world, you don't have to run multiple tests. As long as you get one result that meet all three criterion you are certain the storage meets the requirement. But if you want to find out the maximum it can support up to, you will have to get a failure test.
If it is not possible to achieve the right IOPS value by modifying the thread count it becomes necessary to modify the Sluggishsessions value within the JetStressConfig.xml file. The Sluggishsessions value adds a pause between each task. This allows a level of fine-tuning over the workload dispatched by JetStress. As Sluggishsessions is increased the achieved IOPS value decreases. To change the value, open the JetStressConfig.xml file and look for the default configuration option
<SluggishSessions>1</SluggishSessions>
Modify the value, save the configuration file and then re-start JetStress.
Use the table below as a guide to determine what to do next after each test till you get a satisfying result.
Monday, September 26, 2011
Exchange 2010 DAG Network Configuration
I have seen many DAG deployments with mis-configuration for DAG networks, especially when the DAG is accross multiple sites. I am posting an example configuration here to show how the DAG networks should be set up.
The example makes the following assumption:
IP address Configuration
By default, the DAG network will be set up like this:
The problem of this configuration is the cross-site log repliation will use the MAPI NIC on the servers instead of using the dedicated Replicaiton NIC because there is no DAG network that has been defined between 10.1.10.0/24 and 10.1.20.0/24.
The solution is to collapse default DAG networks as below:
The example makes the following assumption:
- 2 AD Sites: Site1 & Site2
- 4-node DAG with each Site having two DAG nodes
IP address Configuration
Server | Network\IP |
MBX1 | MAPI: 192.168.10.11 Replication: 10.1.10.11 |
MBX2 | MAPI: 192.168.10.12 Replication: 10.1.10.12 |
MBX3 | MAPI: 192.168.20.13 Replication: 10.1.20.13 |
MBX4 | MAPI: 192.168.20.14 Replication: 10.1.20.14 |
By default, the DAG network will be set up like this:
DAG Network Name | Subnets | Interfaces |
DAGNetwork01 | 192.168.10.0/24 | 192.168.10.11 192.168.10.12 |
DAGNetwork02 | 10.1.10.0/24 | 10.1.10.11 10.1.10.12 |
DAGNetwork03 | 192.168.20.0/24 | 192.168.20.13 192.168.20.14 |
DAGNetwork04 | 10.1.20.0/24 | 10.1.20.13 10.1.20.14 |
The problem of this configuration is the cross-site log repliation will use the MAPI NIC on the servers instead of using the dedicated Replicaiton NIC because there is no DAG network that has been defined between 10.1.10.0/24 and 10.1.20.0/24.
DAGNetwork01 | DAGNetwork02 | DAGNetwork03 | DAGNetwork04 | |
DAGNetwork01 | MAPI | - | MAPI\Replication | - |
DAGNetwork02 | - | Replication | - | - |
DAGNetwork03 | MAPI\Replication | - | MAPI | - |
DAGNetwork04 | - | - | - | Replication |
The solution is to collapse default DAG networks as below:
DAG Network Name | Subnets | Interfaces | Replication Enabled |
DAGNetwork01 | 192.168.10.0/24 192.168.20.0/24 | 192.168.10.11 192.168.10.12 192.168.20.13 192.168.20.14 | No |
DAGNetwork02 | 10.1.10.0/24 10.1.20.0/24 | 10.1.10.11 10.1.10.12 10.1.20.13 10.1.20.14 | Yes |
Make sure log replication is disabled on DAGNetwork01 so that log shipping will always use the replicatio NICs first, but will still fail over to the MAPI NICs. If you don't disable replication on DAGNetwork01, DAGNetwork01 will have the same weight as DAGNetwork02 when the servers choose to ship logs.
Thursday, September 15, 2011
Hardware Load Balancing a Relay Connector
This is not a re-post of Pmeijden's blog, but you should read his blog first in order to understand what I am trying to show here.
One of the solutions mentioned in his article is to
1. Add HLB IP to the Anonymous Relay connector on each HT server.
2. Create IP Allow rules with a default Block rule on the HLB to control who can relay
Now inbound mail will hit the Default Receive Connector while relay mail will hit the Anonymous Relay Connector.
1. Add HLB IP to the Anonymous Relay connector on each HT server.
2. Create IP Allow rules with a default Block rule on the HLB to control who can relay
This has been proved to work. But if email from outside also goes through the HLB, inbound email will hit the Anonymous relay connector instead of Default Receive Connector since the Anonymous Relay Connector has a specific IP defined. This would still work if you have any hosted service (Postini, FOPE, etc) or another OnPrem email gateway. All you have to do is to add Postini\FOPE\Gateway IP to the allow rule. So your server still cannot be used for open relay.
But what if you don’t have either of those or you just don’t want any other traffic to hit the Anonymous Relay connector (for logging\troubleshooting purpose). So the solution is to do the following:
- Add additional NIC to each HT server with additonal IP
- Change the Default Receive Connector to listen on the original IP\NIC and the Anonymous Receive Connector to listen on the additional IP\NIC.
- Create a 2nd VIP on the HLB to balance between the additional IPs over TCP 25
- Add HLB IP to the Anonymous Relay Connector.
- On the HLB, create IP allow\block rule to only allow specific IPs to hit the 2nd VIP.
Saturday, September 10, 2011
LyncSocial is out
LyncSocial (Beta) is the first FREE application for Microsoft Lync that allows users to update your Lync, Twitter and LinkedIn statuses simultaneously. LyncSocial is a simple way to enhance your social media presence without taking the extra time to login and post to different platforms. Simply include #TW for Twitter or #LI for LinkedIn in your Lync status to automatically update these platforms.
LyncSocial can be downloaded here.
LyncSocial can be downloaded here.
Wednesday, September 7, 2011
Exchange 2010 Certificate Planning
I feel it’s necessary to make some standard clarification here to facilitate any future E2010 deployment.
1. Wildcard certificate not recommended due to Lync. Always use UCC cert that support SAN name. But if you do use wildcard, remember to set EXPR Provider to msstd:*.contoso.com.
2. You do NOT put the actual CAS array name into the certificate. The only place cas array name is being used is the RPCClientAccessServer attribute for mailbox database. Outlook clients will use this for MAPI\RPC connection. It’s not over HTTPS, so no need to put that in the cert. Normally the cas array name will be the internal FQDN, such as casarray.contoso.local. But if you happen to have internal domain name be the same as external domain name, make sure you DO NOT have a DNS record for cas array name. If you do, this will slow down the initial connection of Outlook Anywhere. Do not use the actual CAS array name (casarray.contoso.local or casarray.contoso.com) as the URL for any virtual directory (owa, ecp, activesync, ews, oab, etc). Create a different name such as owa.contoso.local for the internal URL.
3. If you have ISA\TMG at front, issue a cert using internal CA for the backend exchange server. The public cert should go on to ISA\TMG or load balancer if you do SSL offloading.
4. I wouldn’t recommend to put the internal server FQDN to the public cert (and you really don’t need to) as this will expose your server to the outside world.
5. So in a nutshell, the basic names you would need in the cert would be:
Owa.contoso.com
Autodiscover.contoso.com
Legacy.contoso.com (if doing co-exist)
failback.contoso.com (for datacenter failover and failback)
smtp.contoso.com (if secure SMTP is required)
References:
Just based on my understanding and experience. Any comments is highly welcomed.
Friday, August 5, 2011
Move mailbox from Exchange 2010 On Premise to Office 365
Screenshots below outlines the process of moving a mailbox from on-premise Exchange 2010 enviroment to Office 365.
Assumptions:
1. From EMC On-Premise, go to Recipient Configuration -> Mailbox, highlight the mailbox you are going to move, click New Remote Move Request from the Action pane
2. Choose Office 365 as the target forest; specify external URL of your co-exist Exchange 2010 server with an account that has adequate permission to the on-premise Exchange environment
3. Enter the federated service domain as the Target Delivery Domain
4. After the remote move request has been generated successfully, go to EMC Cloud -> Recipient Configuration- > Move Request to verify the status of the move request. You can also run Get-MoveRequest | Get-MoveRequestStatistics from a remote powershell session that connects to Office 365 to verify the status.
5. The move request has completed successfully.
Assumptions:
- Primary SMTP Domain: CONTOSO.COM
- Federated Service Domain: SERVICE.CONTOSO.COM
- External URL for Co-exist Exchange 2010 server: OWA.CONTOSO.COM
- Rich Co-exist has already been established between On-prem Exchange and Office 365 (refer to Exchange Hybrid Deployment Configuration Tips: Sharing Free/Busy Information and Exchange Server Deployment Assistant on how to)
- Mailbox Replication Proxy Service has been enabled on the co-exist Exchange 2010 server.
1. From EMC On-Premise, go to Recipient Configuration -> Mailbox, highlight the mailbox you are going to move, click New Remote Move Request from the Action pane
2. Choose Office 365 as the target forest; specify external URL of your co-exist Exchange 2010 server with an account that has adequate permission to the on-premise Exchange environment
3. Enter the federated service domain as the Target Delivery Domain
4. After the remote move request has been generated successfully, go to EMC Cloud -> Recipient Configuration- > Move Request to verify the status of the move request. You can also run Get-MoveRequest | Get-MoveRequestStatistics from a remote powershell session that connects to Office 365 to verify the status.
5. The move request has completed successfully.
6. As a result, user4 now is showing as the Contact in on-premise Exchange
And a mailbox in Office 365.
Thursday, August 4, 2011
Exchange 2010 Federated Delegation with TMG
During a recent rich co-exist deploymnet between on-premise Exchange 2010 and Office 365, I noticed therer is a problem establishing organizational relationship from Office 365 to on-premise Exchange coexist server when on-premise Autodiscover is published by a TMG server. Exchange 2010 federation uses SAML tokens—not user accounts—to authenticate against IIS for EWS calls. TMG doesn’t know how to validate SAML tokens, so the incoming requests can’t be authenticated and passed on to the Exchange Server 2010 coexist server. Every time a cloud user tries to view free/busy information of an on-premise user, there is a log in the TMG server indicating "Access Denied"
The end result is that we couldn’t get a proper sharing relationship setup and you can’t federate calendar data.
When we knew what the problem was, fixing it involved modifying the OWA and ECP virtual directories on all of our Exchange Server 2010 CAS servers to perform FBA, then modifying the Web listener on our TMG Server to disable pre-authentication. Finally, we needed to modify the authentication settings for each of the TMG publishing rules for ActiveSync, Outlook Anywhere, and OWA to set them to No Delegation, But Client May Authenticate Directly, and to revise the Users settings from All Authenticated Users to All Users. Revising the Users settings is important; without this, ISA won’t pass any connections on to the CA servers. You may also need to verify that the authentication settings of your other Exchange virtual directories are valid; many organizations will allow basic authentication between TMG and their CAS servers, but require NTLM or Windows Integrated from external clients to TMG.
If you’re using multiple Web listeners to publish Exchange 2010, then your step may be different. The federated delegation feature requires direct access to the EWS vdir on your CAS servers, and EWS is typically published on TMG as part of the Outlook Anywhere rules. If you publish those using a separate Web listener—which will require a separate IP address, FQDN, and SSL certificate—you can simply disable pre-authentication for that Web listener, but still allow it on your OWA, ECP, and EAS directories.
Calendar sharing and TMG FBA pre-authentication are both wonderful features, but at this point they are not compatible.
Monday, July 18, 2011
Exchange Certificate Renewal Causes Lync\Exchange IM Integration Fail
Recently ran into an issue where Lync\Exchange IM Integration stopped working after renewing the certificate on the Exchange server. This was caused by the change of the ThumbPrint of the certificate.
The ThumbPrint of the new certificate has changed and this needs to be updated by running the following Cmdlet
After updating the ThumbPrint, IM is available again in OWA.
The ThumbPrint of the new certificate has changed and this needs to be updated by running the following Cmdlet
After updating the ThumbPrint, IM is available again in OWA.
Friday, July 15, 2011
Outlook Anywhere NTLM Authentication by TMG 2010
This MS White Paper provides a nice step-by-step instruction on how to use TMG\UAG to publish Outlook Anywhere with NTLM authentication. However there are still some "Gotchas" that are not covered in the article.
1. The TMG server must be domain-joined.
2. If your Web Listener uses FBA (in most cases it does) to publsh OWA\ActiveSync\Autodiscover\EWS\OAB, you can't use the same listener to publish Outlook Anywhere. The reason behind this is the nice "FBA Fallback to Basic" feature does not apply to NTLM. As the name implies, it only falls back to Basic, not NTLM. If you try to use the same Listener for Outlook Anywhere with NTLM, you will get promot endlessly for credentials in the Outlook client. So if you want to keep FBA for OWA, you'll have to create a separate Listener for Outlook Anywhere that will use HTTP\Integrated authentication.
So what's the big deal? Well, a separate Listener means the following:
3. So you change the ExternalHostName for Outlook Anywhere to Outlook.contoso.com. And you just add outlook.contoso.com to the existing certificate instead of buying a new one since it's a SAN certificate. Let's say the common name of the SAN certificate is owa.contoso.com, you will get some error below when you run Exchange Remote Connectivity Analyzer against OutlookAnywhere
The certificate common name owa.contoso.com doesn’t validate against the mutual authentication string that was provided: msstd:outlook.contoso.com
As the errro indicates, the MSSTD name must match the common name on the certificate. Since outlook.contoso.com is not the common name on the certificate, the mutual authentication would fail. To fix it, run the following Comlet:
Set-OutlookProvider -CertPrincipalName "msstd:owa.contoso.com"
These are the things I've run into so far. You probably don't have to do it depending on different scenarios.
For those of you who want to know the difference between Basic and NTLM authentication, here are some quick notes from Microsoft.
NTLM authentication
1. The TMG server must be domain-joined.
2. If your Web Listener uses FBA (in most cases it does) to publsh OWA\ActiveSync\Autodiscover\EWS\OAB, you can't use the same listener to publish Outlook Anywhere. The reason behind this is the nice "FBA Fallback to Basic" feature does not apply to NTLM. As the name implies, it only falls back to Basic, not NTLM. If you try to use the same Listener for Outlook Anywhere with NTLM, you will get promot endlessly for credentials in the Outlook client. So if you want to keep FBA for OWA, you'll have to create a separate Listener for Outlook Anywhere that will use HTTP\Integrated authentication.
- a new public URL\DNS for Outlook Anywhere
- a new cert that has the URL\DNS as the common name
- a new external IP address for the ULR\DNS
- a new internal IP on the TMG server
- firewall rules changes
IP Address | URL\DNS | Description |
131.107.155.10 | Owa.contoso.com | OWA\ActiveSync |
131.107.155.11 | Outlook.contoso.com | Outlook Anywhere\EWS\OAB |
131.107.155.10 or .11 | Autodiscover.contoso.com | Can be either .10 or .11 |
3. So you change the ExternalHostName for Outlook Anywhere to Outlook.contoso.com. And you just add outlook.contoso.com to the existing certificate instead of buying a new one since it's a SAN certificate. Let's say the common name of the SAN certificate is owa.contoso.com, you will get some error below when you run Exchange Remote Connectivity Analyzer against OutlookAnywhere
The certificate common name owa.contoso.com doesn’t validate against the mutual authentication string that was provided: msstd:outlook.contoso.com
As the errro indicates, the MSSTD name must match the common name on the certificate. Since outlook.contoso.com is not the common name on the certificate, the mutual authentication would fail. To fix it, run the following Comlet:
Set-OutlookProvider -CertPrincipalName "msstd:owa.contoso.com"
These are the things I've run into so far. You probably don't have to do it depending on different scenarios.
For those of you who want to know the difference between Basic and NTLM authentication, here are some quick notes from Microsoft.
Basic authentication
- Basic authentication sends the user's user name and password in clear text – this doesn’t mean the connection is not secure. It’s still encrypted by the SSL layer.
- Basic authentication also requires the user to enter their domain, user name, and password every time they connect to the Client Access server.
NTLM authentication
- NTLM authentication is also known as Integrated Windows authentication. When NTLM authentication is used, the user's credentials aren't sent over the network. Instead, the client computer and the server exchange hashed values of the user's credentials.
- NTLM can also use the current Microsoft Windows operating system logon information.
Thursday, July 14, 2011
Outlook CACHE causing NDR when recreating mailbox during migration
No matter what you do, some mailboxes just fail to move during the migration. My last resort would be to blow the mailbox away on the legacy server, re-create on the new server, then import the PST back to the new mailbox. However, this would cause another headache afterward: other internal users will get NDR when sending emails to the new mailbox due to the Outlook cache. Below is a quick way to fix it without touching each Outlook client to manually delete the cached name:
1. Write down the LegacyExchangeDN value before removing the mailbox. You can do this either using ADSIEDIT.MSC or running the following Cmdlet from EMS:
Get-Mailbox AWang | fl LegacyExchangeDN
2. After you recreate the mailbox on the new server, create a new X500 address for the user and put in the LegacyExchagneDN recorded in step 1.
1. Write down the LegacyExchangeDN value before removing the mailbox. You can do this either using ADSIEDIT.MSC or running the following Cmdlet from EMS:
Get-Mailbox AWang | fl LegacyExchangeDN
2. After you recreate the mailbox on the new server, create a new X500 address for the user and put in the LegacyExchagneDN recorded in step 1.
Wednesday, July 13, 2011
Exchange Server and Update Rollups Builds Numbers
http://technet.microsoft.com/en-us/library/hh135098.aspx
Exchange Server
Exchange Server 2007 Service Pack 1
Exchange Server 2007 Service Pack 2
Exchange Server 2007 Service Pack 3
Exchange Server 2010
Exchange Server 2010 Service Pack 1
Exchange Server
| Product name | Build number | Date |
| Microsoft Exchange Server 2003 | 6.5.6944 | 6/30/2003 |
| Microsoft Exchange Server 2003 SP1 | 6.5.7226 | 5/25/2004 |
| Microsoft Exchange Server 2003 SP2 | 6.5.7638 | 10/19/2005 |
| Microsoft Exchange Server 2007 | 8.0.685.24 | 12/9/2006 |
| Microsoft Exchange Server 2007 | 8.0.685.25 | 12/9/2006 |
| Microsoft Exchange Server 2007 SP1 | 8.1.240.6 | 11/29/2007 |
| Microsoft Exchange Server 2007 SP2 | 8.2.176.2 | 8/24/2009 |
| Microsoft Exchange Server 2007 SP3 | 8.3.083.6 | 6/20/2010 |
| Microsoft Exchange Server 2010 | 14.0.639.21 | 11/9/2009 |
| Microsoft Exchange Server 2010 SP1 | 14.1.218.15 | 8/24/2010 |
Exchange Server 2007 Service Pack 1
| Product name | Build number | Date | KB |
| Microsoft Exchange Server Exchange 2007 SP1 | 8.1.240.6 | 11/29/2007 | |
| Update Rollup 1 for Exchange Server 2007 Service Pack 1 | 8.1.263.1 | 2/28/2008 | KB945684 |
| Update Rollup 2 for Exchange Server 2007 Service Pack 1 | 8.1.278.2 | 5/8/2008 | KB948016 |
| Update Rollup 3 for Exchange Server 2007 Service Pack 1 | 8.1.291.2 | 7/8/2008 | KB949870 |
| Update Rollup 4 for Exchange Server 2007 Service Pack 1 | 8.1.311.3 | 10/7/2008 | KB952580 |
| Update Rollup 5 for Exchange Server 2007 Service Pack 1 | 8.1.336.1 | 11/20/2008 | KB953467 |
| Update Rollup 6 for Exchange Server 2007 Service Pack 1 | 8.1.340.1 | 2/10/2009 | KB959241 |
| Update Rollup 7 for Exchange Server 2007 Service Pack 1 | 8.1.359.2 | 3/18/2009 | KB960384 |
| Update Rollup 8 for Exchange Server 2007 Service Pack 1 | 8.1.375.2 | 5/19/2009 | KB968012 |
| Update Rollup 9 for Exchange Server 2007 Service Pack 1 | 8.1.393.1 | 7/17/2009 | KB970162 |
| Update Rollup 10 for Exchange Server 2007 Service Pack 1 | 8.1.436.0 | 4/9/2010 | KB981407 |
Exchange Server 2007 Service Pack 2
| Product name | Build number | Date | KB |
| Microsoft Exchange Server 2007 SP2 | 8.2.176.2 | 8/24/2009 | |
| Update Rollup 1 for Exchange Server 2007 Service Pack 2 | 8.2.217.3 | 11/19/2009 | KB971534 |
| Update Rollup 2 for Exchange Server 2007 Service Pack 2 | 8.2.234.1 | 1/22/2010 | KB972076 |
| Update Rollup 3 for Exchange Server 2007 Service Pack 2 | 8.2.247.2 | 3/17/2010 | KB979784 |
| Update Rollup 4 for Exchange Server 2007 Service Pack 2 | 8.2.254.0 | 4/9/2010 | KB981383 |
| Update Rollup 5 for Exchange Server 2007 Service Pack 2 | 8.2.305.3 | 12/7/2010 | KB2407132 |
Exchange Server 2007 Service Pack 3
| Product name | Build number | Date | KB |
| Microsoft Exchange Server 2007 SP3 | 8.3.083.6 | 6/20/2010 | |
| Update Rollup 1 for Exchange Server 2007 Service Pack 3 | 8.3.106.2 | 9/9/2010 | KB2279665 |
| Update Rollup 2 for Exchange Server 2007 Service Pack 3 | 8.3.137.3 | 12/10/2010 | KB2407025 |
| Update Rollup 3 for Exchange Server 2007 Service Pack 3 | 8.3.159.0 | 03/2/2011 | KB2492691 |
| Update Rollup 3-v2 for Exchange Server 2007 Service Pack 3 | 8.3.159.2 | 3/30/2011 | KB2530488 |
| Update Rollup 4 for Exchange Server 2007 Service Pack 3 | 8.3.192.1 | 7/7/2011 | KB2509911 |
Exchange Server 2010
| Product name | Build number | Date | KB |
| Microsoft Exchange Server 2010 RTM | 14.0.639.21 | 11/9/2009 | |
| Update Rollup 1 for Exchange Server 2010 | 14.0.682.1 | 12/9/2009 | KB976573 |
| Update Rollup 2 for Exchange Server 2010 | 14.0.689.0 | 3/4/2010 | KB979611 |
| Update Rollup 3 for Exchange Server 2010 | 14.0.694.0 | 4/9/2010 | KB981401 |
| Update Rollup 4 for Exchange Server 2010 | 14.0.702.1 | 6/17/2010 | KB982639 |
| Update Rollup 5 for Exchange Server 2010 | 14.0.726.0 | 12/13/2010 | KB2407113 |
Exchange Server 2010 Service Pack 1
| Product name | Build number | Date | KB |
| Microsoft Exchange Server 2010 SP1 | 14.1.218.15 | 8/24/2010 | |
| Update Rollup 1 for Exchange Server 2010 SP1 | 14.1.255.2 | 10/4/2010 | KB2407028 |
| Update Rollup 2 for Exchange Server 2010 SP1 | 14.1.270.1 | 12/9/2010 | KB2425179 |
| 14.1.289.3 | 3/7/2011 | KB2492690 | |
| Update Rollup 3-v3 for Exchange Server 2010 SP1 | 14.1.289.7 | 4/1/2011 | KB2529939 |
| Update Rollup 4 for Exchange Server 2010 SP1 | 14.1.323.1 | 6/22/2011 | KB2509910 |
| Update Rollup 4-v2 for Exchange Server 2010 SP1 | 14.1.323.6 | 7/27/2011 | KB2579150 |
Lync FE External Web Services without Reverse Proxy
Lync installation creates two web sites: Internal Web Services and External Web Services.
The internal website is pubished on ports 80/443, while the external site is pubished on 8080/4443. Microsoft recommends to use a reverse proxy server, such as TMG 2010, to publish the external website and redirect 80/443 from the web to the FE server over 8080/4443.
However, in a small Lync environment where a reverse proxy server is not available which usually sits in the DMZ, this can cause external Lync users unable to access the web services, such as Address Book, Conferencing URL, etc. Here is what we can do to provide external web services to external Lync users without reverse proxy.
2. Change the external website to use the additonal IP address on port 80/443 from IIS Mananger
3. Assign a 3rd-party certificate to the external website using Lync Server Deployment Wizard.
4. Change the firewall to NAT to the additonal IP on the FE server and allow inbound 80/443
You will not be able change port settings for the external web services from the Topology Builder. So just leave it as the way it is.
External Lync users now should be able to access all external web services.
Notes: This can be used as a workaround to bypass reverse proxy for either a small environment where security is not a big convern or in a test\lab enviroment. You should always consider deploying reverse proxy to publish FE servers whenever possible.
The internal website is pubished on ports 80/443, while the external site is pubished on 8080/4443. Microsoft recommends to use a reverse proxy server, such as TMG 2010, to publish the external website and redirect 80/443 from the web to the FE server over 8080/4443.
However, in a small Lync environment where a reverse proxy server is not available which usually sits in the DMZ, this can cause external Lync users unable to access the web services, such as Address Book, Conferencing URL, etc. Here is what we can do to provide external web services to external Lync users without reverse proxy.
- Assign an additional IP address to the FE server
2. Change the external website to use the additonal IP address on port 80/443 from IIS Mananger
3. Assign a 3rd-party certificate to the external website using Lync Server Deployment Wizard.
4. Change the firewall to NAT to the additonal IP on the FE server and allow inbound 80/443
You will not be able change port settings for the external web services from the Topology Builder. So just leave it as the way it is.
External Lync users now should be able to access all external web services.
Notes: This can be used as a workaround to bypass reverse proxy for either a small environment where security is not a big convern or in a test\lab enviroment. You should always consider deploying reverse proxy to publish FE servers whenever possible.
Thursday, June 30, 2011
Exchange 2010 Dial-Tone Recovery
Both Exchange 2003 and Exchange 2007 provide a GUI way of doing Dial-tone database recovery. Unfortunately this has to be done by PowerShell in Exchange 2010. You can find the official Microsoft "How to" article from here . This post is trying to make the process look more easier and user-friendly with adequate screenshots step-by-step.
First, let's verify my test user is able to access his mailbox while the database is mounted.
Next, let's delete the entire directory where the database and logs reside.
As a result, the database is dismounted and user cannot access OWA.
Now, let's start the recovery process!
Use the New-MailboxDatabase cmdlet to create a dial tone database, as shown in this example.
Use the Set-Mailbox cmdlet to rehome the user mailboxes hosted on the database being recovered (Mailbox Database) to the newly created dial-tone database (DTDB1), as shown in this example.
Notice if the database being recovered also hosts the arbitration mailboxes, you need to run the following Cmdlet to rehome the arbitration mailboxes as well:
Now let's mount the new dial-tone database.
Use the New-MailboxDatabase cmdlet with the -Recovery switch to create a Recovery Database
Caution: Do not mount the recovery database.
At this point, users should be able to access their email. They will have an empty mailbox without any history.
Well, this should remove a lot pressure off of your shoulder now. The next step is to take you time to recover the database from your favorite backup program.
Depending on the backup program, you can either restore to an alternative location or restore directly to the recovery database.
After restore completes, run the following command to verify the state of the database:
Most likely the database will be in "Dirty Shutdown" state. Don't panic, this can be fixed! Pay attention to "Log Required" and "Log Committed". In my example, I am missing log E0200000X3D. If you are lucky enough to have all the missing log files, you can just run the following command to replay those log files into the database:
If you can't locate the missing log files, you will have to run ESEUTIL in repair mode (/p) to repair the database to bring it into Clean Shutdown state.
Refer to this for complete ESEUTIL usage.
Now, all you have to do is to make sure the database and log files exist under the recovery database directory and rename the database to be the name of the recovery database.
Mount the recovery database
The recovery database should mount successfully.
Now, we are ready to swap the Dial-tone database with the recovery database.
Dismount the dial-tone database and the recovery database. There will be a service interruption after you dismount the dial-tone database.
Set both databases to be restorable
Swap files in the dial-tone database directory with the files in the recovery database directory.
Rename dial-tone database to recovery database.
Rename recovery database to dial-tone database.
Now, mount both databases.
Service should be resumed and user will be able to access their mailbox again with all history.
Are we done yet? No, there is still data left in the current RDB database which was originally the dial-tone database. These data need to merged back to the current production database.
Use the Get-Mailbox and Restore-Mailbox cmdlets to export the data from the RDB and import it into the production database.
Congratulations, You have now successfully recovered the database!
P.S:
In a real world example, I didn't have to create a new database as the dial-tone. Instead I just renamed the failed database into something else and tried to mount it. The mounting process will create an empty database and you can just use this as your dial-tone. If you do this there is no need to rehome all the mailboxes.
First, let's verify my test user is able to access his mailbox while the database is mounted.
Next, let's delete the entire directory where the database and logs reside.
As a result, the database is dismounted and user cannot access OWA.
Now, let's start the recovery process!
Use the New-MailboxDatabase cmdlet to create a dial tone database, as shown in this example.
Use the Set-Mailbox cmdlet to rehome the user mailboxes hosted on the database being recovered (Mailbox Database) to the newly created dial-tone database (DTDB1), as shown in this example.
Notice if the database being recovered also hosts the arbitration mailboxes, you need to run the following Cmdlet to rehome the arbitration mailboxes as well:
Use the New-MailboxDatabase cmdlet with the -Recovery switch to create a Recovery Database
At this point, users should be able to access their email. They will have an empty mailbox without any history.
Depending on the backup program, you can either restore to an alternative location or restore directly to the recovery database.
After restore completes, run the following command to verify the state of the database:
Most likely the database will be in "Dirty Shutdown" state. Don't panic, this can be fixed! Pay attention to "Log Required" and "Log Committed". In my example, I am missing log E0200000X3D. If you are lucky enough to have all the missing log files, you can just run the following command to replay those log files into the database:
Now, all you have to do is to make sure the database and log files exist under the recovery database directory and rename the database to be the name of the recovery database.
Mount the recovery database
The recovery database should mount successfully.
Now, we are ready to swap the Dial-tone database with the recovery database.
Dismount the dial-tone database and the recovery database. There will be a service interruption after you dismount the dial-tone database.
Swap files in the dial-tone database directory with the files in the recovery database directory.
Rename dial-tone database to recovery database.
Rename recovery database to dial-tone database.
Now, mount both databases.
Are we done yet? No, there is still data left in the current RDB database which was originally the dial-tone database. These data need to merged back to the current production database.
Use the Get-Mailbox and Restore-Mailbox cmdlets to export the data from the RDB and import it into the production database.
Congratulations, You have now successfully recovered the database!
P.S:
In a real world example, I didn't have to create a new database as the dial-tone. Instead I just renamed the failed database into something else and tried to mount it. The mounting process will create an empty database and you can just use this as your dial-tone. If you do this there is no need to rehome all the mailboxes.
Subscribe to:
Posts (Atom)