Archive for Exchange 2010

Load Balancing Exchange 2010 Using Cisco ACE – Part 1

Posted in Exchange Server with tags , on March 27, 2010 by Karim Hamdy

Hi , it is been a while since I posted in our blog . In this article we will talk about Load balancing CAS Servers in Exchange 2010 using Cisco ACE 4710. So let’s get started.

First we will need to talk about some terminologies and concepts.

Stickiness:

Also Called Persistence or Affinity , it is the ability to “Stick” the connection to the same Real Server  for the client, for example imagine a web site for banking or e-Trading the requests from the Client has to go to the same Real Server until the client disconnects or ends the session.

Sticky Types

The ACE appliance supports stickiness based on:

HTTP cookies

Client cookies uniquely identify clients to the ACE and the servers providing content. A cookie is a small data structure within the HTTP header that is used by a server to deliver data to a Web client and request that the client between the client and the server.

When the ACE examines a request for content and determines through policy matching that the content is sticky, it examines any cookie or URL present in the content request. The ACE uses the information in the cookie or URL to direct the content request to the appropriate server.

The ACE supports the following types of cookie stickiness:

Dynamic cookie learning

You can configure the ACE to look for a specific cookie name and automatically learn its value either from the client request HTTP header or from the server Set-Cookie message in the server response. Dynamic cookie learning is useful when dealing with applications that store more than just the session ID or user ID within the same cookie. Only very specific bytes of the cookie value are relevant to stickiness.

By default, the ACE learns the entire cookie value. You can optionally specify an offset and length to instruct the ACE to learn only a portion of the cookie value.

Alternatively, you can specify a secondary cookie value that appears in the URL string in the HTTP request. This option instructs the ACE to search for (and eventually learn or stick to) the cookie information as part of the URL. URL learning is useful with applications that insert cookie information as part of the HTTP URL. In some cases, you can use this feature to work around clients that reject cookies.

Cookie insert

The ACE inserts the cookie on behalf of the server upon the return request, so that the ACE can perform cookie stickiness even when the servers are not configured to set cookies. The cookie contains information that the ACE uses to ensure persistence to a specific real server.

HTTP headers

You can use HTTP-header information to provide stickiness. With HTTP header stickiness, you can specify a header offset to provide stickiness based on a unique portion of the HTTP header

IP addresses

You can use the source IP address, the destination IP address, or both to uniquely identify individual clients and their requests for stickiness purposes based on their IP netmask. However, if an enterprise or a service provider uses a megaproxy to establish client connections to the Internet, the source IP address no longer is a reliable indicator of the true source of the request. In this case, you can use cookies or one of the other sticky methods to ensure session persistence.

HTTP content

allows you to stick a client to a server based on the content of an HTTP packet. You can specify a beginning pattern and ending pattern, the number of bytes to parse, and an offset that specifies how many bytes to ignore from the beginning of the data

Layer 4 payloads

Layer 4 payload stickiness allows you to stick a client to a server based on the data in Layer 4 frames. You can specify a beginning pattern and ending pattern, the number of bytes to parse, and an offset that specifies how many bytes to ignore from the beginning of the data.

RADIUS attributes

RADIUS stickiness can be based on the following RADIUS attributes:

•Calling station ID

•Username

RTSP headers

RTSP stickiness is based on information in the RTSP session header. With RTSP header stickiness, you can specify a header offset to provide stickiness based on a unique portion of the RTSP header.

*Real Time Streaming Protocol (RTSP) is a network control protocol designed for use in entertainment and communications systems to control streaming media servers. The protocol is used to establish and control media sessions between end points.

SIP headers

SIP header stickiness is based on the SIP Call-ID header field. SIP header stickiness requires the entire SIP header, so you cannot specify an offset.

*Session Initiation Protocol (SIP) is a signaling protocol, widely used for controlling multimedia communication sessions such as voice and video calls over Internet Protocol (IP).

Access the ACE CLI using HyperTerminal for Windows by following these steps:

1. Launch HyperTerminal.

2. Enter a name for your connection in the Name field.

3. Click OK.

4. From the Connect using drop-down list, choose the COM

port to which the device is connected.

5. Click OK.

6. Set the port properties:

Bits per second = 9600

Data bits = 8

Parity = none

Stop bits = 1

Flow control = None

7. Click OK to connect.

1.At the login prompt, log into the ACE by entering the login username admin and password. By default, the username and password are admin. For example, enter:

Starting sysmgr processes.. Please wait…Done!!!

switch login: admin

Password: admin

2. At the Enter the new password for “admin”: prompt, change the default Admin password. If you do not change the default Admin password, after you upgrade the ACE software you will only be able to log in to the ACE through the console port.

Enter the new password for “admin”: xxxxx

Confirm the new password for “admin”: xxxxx

admin user password successfully changed.

3. At the Enter the new password for “www”: prompt, change the default www user password. If you do change the default www user password, the www user will be disabled and you will not be able to use Extensible Markup Language (XML) to remotely configure an ACE until you change the default www user password.

Enter the new password for “www”: xxxxx

Confirm the new password for “www”: xxxxx

www user password successfully changed.

Caution At this point, you should consider whether you plan to configure the ACE using the Device Manager GUI or using the CLI. If you have a trunking network setup, or if your VLAN 1000 has been used, you should bypass the following setup script and use the CLI

4. At the “Would you like to enter the basic configuration dialog? (yes/no)” prompt, press Enter to continue the setup. To bypass setup and directly access the CLI, type no.

Would you like to enter the basic configuration dialog? (yes/no) [y]:

Note The ACE provides a default response in brackets [ ] for each question in the setup script. Accept the default response to a configuration prompt by pressing Enter.

5. Select port 1 to carry management VLAN communication by pressing Enter.

Enter the Ethernet port number to be used as the management port (1-4):? [1]:

6. Assign an IP address for the management VLAN interface by entering 172.25.91.110.

Enter the management port IP Address (n.n.n.n): [192.168.1.10]: 172.25.91.110

7. Accept the default subnet mask for the management VLAN interface by pressing Enter.

Enter the management port Netmask(n.n.n.n): [255.255.255.0]:

8. Assign the IP address of the gateway router (the next-hop address for this route) by entering 172.25.91.1.

Enter the default route next hop IP Address (n.n.n.n) or <enter> to skip this step: 172.25.91.1

9. Examine the entered values.

Summary of entered values:

Management Port: 1

Ip address 172.25.91.110

Netmask: 255.255.255.0

Default Route: 172.25.91.1

10. Review the configuration details by pressing d.

Submit the configuration including security settings to the ACE Appliance? (yes/no/details): [y]:

interface gigabitEthernet 1/3

switchport access vlan 1000

no shut

access-list ALL extended permit ip any any

class-map type management

match-any remote_access

match protocol xml-https any

match protocol dm-telnet any

match protocol icmp any

match protocol telnet any

match protocol ssh any

match protocol http any

match protocol https any

match protocol snmp any

policy-map type management first-match remote_mgmt_allow_policy

class remote_access

permit

interface vlan 1000

ip address 172.25.91.110 255.255.255.0

access-group input ALL

service-policy input remote_mgmt_allow_policy

no shutdown

ssh key rsa

ip route 0.0.0.0 0.0.0.0 172.25.91.1

11. Accept this configuration by pressing Enter; otherwise, press n.

Submit the configuration including security settings to the ACE Appliance? (yes/no/details): [y]:

12. After you select y, the following message appears.

Configuration successfully applied. You can now manage this ACE Appliance by entering the url ‘https://172.25.91.110′ into a web browser to access the Device Manager GUI.

After you have completed the setup script, the command prompt appears.

switch/Admin#

After you specify a Gigabit Ethernet port, port mode, and management VLAN, the setup script automatically applies the following default configuration:

  • A Management VLAN is allocated to the specified Ethernet port.
  • An extended IP access list that allows IP traffic originating from any other host addresses.
  • A traffic classification is created for management protocols HTTP, HTTPS, ICMP, SSH, Telnet, and XML-HTTPS. HTTPS is dedicated to connectivity with the Device Manager GUI.
  • A VLAN interface is configured on the ACE.

Assigning a Name to the ACE

The hostname is used for the command-line prompts and default configuration filenames. When you establish sessions to multiple devices, the hostname helps you keep track of which ACE you are entering commands to. By default, the hostname for the ACE is switch.

For example, change the hostname of the ACE from switch to host1 by entering:

switch/Admin# Config

switch/Admin(config)# hostname host1

The prompt appears with the new hostname.

host1/Admin(config)#

Logging in to the ACE

You can access the ACE Device Manager GUI through a web-based interface. Log in to the Device Manager by following these steps:

1. Navigate to the ACE Device Manager by entering the secure HTTPS address or hostname of the ACE in the address field of a web browser. For the example setup shown earlier in Figure 1, enter:

https://172.25.91.110/

2. Click Yes at the prompt to accept (trust) and install the signed certificate from Cisco Systems, Inc. To avoid having to approve the signed certificate every time you log in to the Device Manager, accept the certificate.

  • 3. In the User Name field, type admin for the admin user account.
  • 4. In the Password field, type the new password that you entered
  • 5. Click Login. The default window that appears is the Virtual Contexts window with the Admin context listed, as shown in Figure 7.
  • Virtual Contexts Pane (Admin Context)

The “default” resource class works well for basic configurations that do not need sticky session persistence. For sticky session persistence, you need a resource class that allocates more than 0% of the “Sticky” resources. For each context in which you configure stickiness, you must do the following:

–Configure a resource class in the Admin context that you can associate with one or more contexts where you want to configure stickiness.

Creating a Resource Class

Create a resource class by following these steps:

1. Choose Config > Virtual Contexts > System > Resource Class.

Next we will start by configuring VLAN interfaces required for operation :

Create VLAN interface and give it an IP address , Netmask and enable it

Enable the Physical Interface and give it a name and assign it to a VLAN interface


Adding NAT Pools

Next create a NAT pool by clicking on the NAT pools link. you need a NAT pool as it provides a set of IP addresses that ACE can use as source addresses when sending requests to the real servers. The NAT pool must be configured on the same VLAN interface that you identified or created

For VLAN ID, specify the VLAN number from the VLAN Interfaces step. Use the NAT Pool ID set in the field or enter your own. Then enter the IP address range for the NAT pool using the Start IP Address and End IP Address or Netmask fields.

The NAT pool can be as small as single IP address and it can even re-use the virtual IP (VIP) you plan to use for the application. However, NAT pools with more IP addresses allow more concurrent requests to the real servers. ACE allows several thousand concurrent connections per NAT pool IP address, as long as port address translation (PAT) is enabled. With PAT disabled, ACE can only handle one connection per NAT pool IP address

This Concludes Part 1 , In Part 2 we will configure Virtual Server , Real Servers , Farms and Sticky Groups and SSL Proxy Service so stay tuned.


Advertisements

Exchange 2010 Client Access Server – What is new in Architecture level 300 – Part 1 Arabic

Posted in Exchange Server with tags , , , on March 26, 2010 by Mahmoud Magdy

Exhcange 2010 Session 2 – Upgrade and Coexistence with Exhcange 2003/2007 – Arabic Sessions

Posted in Exchange Server with tags , , , , , on March 5, 2010 by Mahmoud Magdy

http://vimeo.com/9957365

Update Rollup 2 for Exchange Server 2010 (KB979611)

Posted in Exchange Server with tags , on March 5, 2010 by Karim Hamdy

Just released !

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=6d3ae3e0-3982-46d6-9e9c-7d7d63fae565

Dude, Where is my Backup – Understanding Exhcange 2010 backupless Configuration

Posted in Exchange Server with tags , , , , on February 9, 2010 by Mahmoud Magdy

When I started writing this post, I couldn’t get the movie “Dude, Where’s My Car?” and its events out of my head for two reasons.   The first reason is that the conundrum the film’s characters find themselves in reminds me of a similar event in which one of my customers experienced an Exchange disaster and I was brought in to assist.  I realized straightaway the client needed to perform a backup, and when I informed the Exchange Administrator of this he frantically turned to his Backup Administrator and asked him, ‘Dude, where’s my backup?!’  

The second reason I could not shake this movie from my mind while writing this piece is because the same clueless looks that the film’s starring actors had on their faces were identical to the look on the face of the Backup Admin when asked that infamous question.  In fact, I see that look on many of my customers’ faces when I ask them to restore an Exchange backup set for me! 

Backups in Exchange have always been a point of concern for me due to my experiences while working as an Infrastructure Manager.  In one instance I thought I had done everything I should have:  I had everything in place, our Exchange was up and running and I assigned a team to backup Exchange, AD, SQL and most of our critical systems.   We tested the restore steps and everything ran smoothly, but when we had a disaster you can already predict what happened – we experienced another backup set failure which cost us two hours of downtime. 

The secret to successfully restoring Exchange has always been a mystery.  A successful restore even for an Exchange guru is a tedious task!  We are fortunate that today we have assistance in the form of DB portability, power shells, and wizards for backups and restores; but even with this help, the task of restoring Exchange remains tedious.

Other issues that arose with the introduction of Exchange 2007 were the single item and single mailbox restoration.  It is now possible to restore a single mailbox, or better yet a single item, but clever software is needed to perform the task.  You must also properly train and prepare your IT staff, and remember that the software and hardware requirements for either type of restoration are expensive.   You must carefully compare your options when purchasing decent backup software since their prices can be high.

You say you want a revolution…

Well you know, when Microsoft introduced Exchange 2010 that’s exactly what they brought.  For the first time, Microsoft is recommending that administrators perform backup-less deployments.  When I heard that I laughed out loud, as I am sure many of you are, since for years as consultants and as customers we have always been told to backup everything, most importantly our Exchange data, so just exactly how will this revolution of backup-less Exchange deployments change the world?

So Microsoft has a real solution…

Would you like to hear the plan? If you are shocked by this new recommendation then let me set your mind at ease : ‘it’s gonna be alright.’ If you feel like it will take awhile for you to trust Microsoft’s recommendation then you are not alone.  It took me, a technically savvy (and extremely humble) guy nearly 3 months to accept this fact, but what it really took was for me to design a backup-less configuration for the first time.  After designing this configuration I have learned the benefits of going backup-less, so please join me as I explain them to you.

Backups’ Background:

Historically, I have always considered Exchange backups to be more important than Exchange itself. ‘Why?’ you might ask.  My answer is multi-fold:  because it guarantees that I will be back online in the blink of an eye if the system goes down.  Plus , it will enable me to recover items for users that have been hard deleted, and more importantly this is the only way to flush and delete the logs of the mailbox database (previously this was tied to the Storage Group.)  The other not-so-popular method of deleting such logs is known as circular logging.

Backup in Exchange 2003 was straight forward, but with Exchange 2007 Microsoft introduced the concept of database copies which provided a new way to backup your Exchange data.

Now you can perform a backup from the passive copy, which provides enough data to help you discern what the online copy is suffering from (i.e. IOPs, users access, AV Scan.)  When you back up the passive copy, and the backup to the passive copy is complete, then the database is marked as backed up and logs are deleted from passive and active copy.

As mentioned previously, doing Exchange backups historically required costly backup software as well as hardware, including storage, backup tapes, tapes libraries, and backup hustle.

Microsoft made a bold decision to change the Exchange world by introducing backup-less configuration, which I will now discuss in more detail.

Less is more, don’t you agree?

What does backup-less really mean?  It simply means that you do not have to backup your Exchange data, or at the very least it gives you the ability for the first time to not have to back it up.

I can completely understand many of you doubting that this is in fact a possibility, to never have to backup your Exchange data, but before you make your decision let us explore Backup-less architectures and learn how they really work. 

Backup-Less Architecture:

As stated above, backup in E12 could be done to the passive copy but this is only true for CCR of LCR.  At the time, this was a viable option: to backup the passive node and then once backup is done the passive copy updates the database header, notifies the active node, and the active node deletes the logs.

Issues to consider before designing or deploying a Backup-less configuration:

–          Data protection, Database health, Database recovery.

–          What to do when you lose data.

–          How to delete your logs.

–          How to restore items and mailboxes like before.

In order to address these issues, you must understand how Backup-less Configurations work:

When you want to configure your Exchange in Backup-less, you should have at least two copies of the data (Active/Passive.) Microsoft recommends doing Backup-less in more than 3 copies (Active/Passive/Passive) configuration. In order to configure your infrastructure to be Backup-less, you must obtain three copies of the data and configure circular logging on the mailbox database.

I can hear you saying, ‘Circular logging?! No way!’ And I understand your reaction, but keep in mind we never do circular logging unless we have strong reason to, so let us see how circular logging works with the Backup-less.

Real World Example:

To illustrate how circular logging works with backup-less, let us consider the following example:

You have a mailbox store called MB1 that has 3 copies of it on Servers 1, 2 and 3. MB1 is active on Server 1 and has two copies on Servers 2 and 3. Now you want to configure it in Backup-less.   All you have to do is configure the mailbox database to do circular logging, and once you do so Exchange will change its architecture slightly and perform circular logging in another way.

When circular logging is enabled on the database, the logs are written to the Hard disk.  Once the data is committed to the database, logs will be flushed.   In Backup-less (DAG environment only) this changes the Exchange behavior: logs are written but never get flushed until logs are replicated and marked as checked at the other database copies.

To understand this, let us go back to our example: MB1 has log E01 that is waiting to be written.  E01 is written to the DB and now it gets held in Server 1 when before it would have gotten flushed.

Server 1 replicates E01 to Server 2, Server 2 copies the log and it remains in Server 1 where it checks the logs and marks it as healthy/inspected and notifies Server 1.   Server 1 does the same with Server 3 and once Server 3 verifies its logs and reports to Server 1 that its copy of E01 is healthy/inspected, then Server 1 deletes and flushes the logs.

There are 2 questions that might arise at this point:

–          Why didn’t Exchange wait until the log is replayed at Server 2 and Sever 3?

–          Does Server 1 wait until it replicates the data to all of its adjacent servers? (In our example server 2 and server 3)

The answer to the first question is Exchange will not wait for the log replay because you might have a lagged replay configured on your DB copy.   This means that you might replay the logs 48 hours later which translates into huge numbers of logs for Exchange.

I do not have a confirmed answer to the second question yet, but if you attended an Exchange 2010 Advanced storage session you will know that an Exchange server can recover and resend the logs, and even better, the specific bits in case of database corruption.  But if Server 1 deletes its logs and the same for Server 2, then where does Server 3 get its logs from?

Hopefully by now the answer to that question is a little bit clearer.   Exchange now has a self-based mechanism to flush its logs, but Backup-less configuration is not a specific setting that you assign to Exchange.  By that I mean you don’t go to the options page and check the box stating this is a Backup-less organization; rather, this is a group of configurations that you apply to Exchange so you can deploy a Backup-less configuration.  It is important to remember that this behavior is the same if you have 2 copies and do circular logging, even if you do backup.

There are several pertinent questions that we should answer one at a time:

–          What about the health of my Database, Database availability, and uptime?

Exchange 2010 has a self-healing mechanism.   What that means is that if page No. 485950 gets written to a bad block, or gets corrupted logically or physically, then Exchange 2010 can replicate this page from another server by copying only the required page with the next replication cycle.   This keeps the Exchange database healthy and minimizes the replication requirements.

If Exchange cannot make the active database healthy then we have DAGs that pick the best available copy and make it an active copy.   Typically if a physical server failed, a Hard disk failed, or a database failed physically or logically, you would not need your backup since you already have two copies.  This means you don’t need your backup!  (Are you becoming a backup-less fan yet?)

Now the other dimension is minimizing the storage cost.  Since you have three copies of the database, and since Exchange 2010 has 70% less IOPs, you no longer need expensive SCSI disks, or even a SAN.  I recommend using a JBOD configuration which is much more cost effective than any other storage option.  Thus, in a backupless configuration, you can have three copies of your data and reduce both the backup software and hardware cost.  (Considering jumping on the backup-less bandwagon now?)

–          What should I do if I want to replace a single item or a mailbox?

Before answering that, first ask yourself how many times as an Exchange admin you had to do that (restore an item or mailbox for a user).  In my career, I only had to do it at most three to five times.   It might be different in your organization, but in general most Exchange administrators do not need to do that on regular basis.

Since we have cheaper storage we can increase the mailbox store dumpster.   It is set at 14 days by default, but now you can increase it and ask the users to recover their mailbox store.   You can also use the new RBAC  (role-based access control) model and give helpdesk personnel  the permission to search the Exchange dumpster and perform discovery within it using PowerShell in order to recover items for users…..meaning you as the Exchange Admin does not have to!

–          Don’t I need a backup at all?

I will not say that you don’t need to backup the Exchange system at all, but you might want to consider backing it up as a second layer of protection.  If you do perform a backup-less configuration, then your first line of defense is not the backup sets any more, it is your Exchange 2010 Backup-less configuration,.  In other words, it is done automatically.

I know after being told for years to backup everything, most especially Exchange data, so I know it will be difficult to change your thinking radically with a single article.  You probably have legislations that make you comply with 3 years’ restore SLA.   But if you are one of the Exchange admins that do not have to abide by such legislations, then you should consider Backup-less Configuration.

Hopefully you now understand the architecture change of the circular logging, DAGs, and how to do backup-less configurations.   Backup-less configuration is still an un-documented feature of Exchange 2010 and you will not find much information about it.   My recommendation is that you open your mind to the idea and take care in calculating the total cost required for backup gear as compared to the B-less cost, without forgetting their technical and operational requirements as well.  I cannot say that backup-less is for everyone, but it is a great option that can save you money, and one you should give decent thought to. 

I look forward to bringing you another thought-provoking article within a month, and until that time I wish you the best uptimes and the fastest Exchange servers!