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.
  1. 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.
  2. Is the I/O Database Reads Average Latency in the test report < 20ms?
  3. Is the I/O Log Writes Average Latency in the test report < 10ms?
The test will show Failed if neither 2 or 3 is met. However, you will have to determine No.1 by comparing the Achieved Transactional I/O per Second in the test report with the Total Database Required IOPS / Server predicted in the Mailbox Role Calculator.

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:
  1. Total Number of Tier-X user Mailboxes / Environment
  2. Total Send /Receive Capability / Mailbox / Day
  3. Number of database / Server
So when you run JetStress you should generate enough load on the server so that the total IOPS achieved by the test is higher than what is predicted by the Mailbox Role Calculator. If the number is higher, the first criterion is than met. But it doesn't mean the test succeeds. You still have to make sure both No.2 and No.3 are met. As the Achieved Transactional I/O per Second increases,  I/O Database Reads Average Latency and I/O Log Writes Average Latency also increase.

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:
  • 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

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
Note: do not add the additional IP to the existing NIC as this will also register the additonal IP on the DNS server. If you use an additional NIC, you can then disable DNS registration on the NIC. Also, you do not need to define Default Gateway for the additoinal NIC since it only needs to talk to the load balancer which is on the same subnet.
  • 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.    

Now inbound mail will hit the Default Receive Connector while relay mail will hit the Anonymous Relay Connector.

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.

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:
  • Primary SMTP Domain: CONTOSO.COM
  • Federated Service Domain: SERVICE.CONTOSO.COM
  • External URL for Co-exist Exchange 2010 server: OWA.CONTOSO.COM
Prerequisites:
Steps:

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.