Windows Management and Scripting

A wealth of tutorials Windows Operating Systems SQL Server and Azure

Archive for the ‘Exchange’ Category

Articles , Tutorials and reviews about Microsoft Exchange servers

Troubleshooting Exchange 2010 virtual directory re-creation

Posted by Alin D on May 18, 2012

Ever since Exchange Server 2010 Service Pack 1 dropped, administrators have had two methods to recreate the six Exchange virtual directories: reset them or reinstall the client access server role. Files are occasionally misconfigured or damaged by third-party apps, however, leaving virtual directories unusable. The virtual directory re-creation process is straightforward and well-documented, but it doesn’t always work, and troubleshooting is sometimes necessary.

Exchange Server 2010 SP1 was the first version of Exchange to allow admins to re-create virtual directories via the Exchange Management Console (EMC). In the Server Configuration node, click Client Access in the right-hand action pane. From there, you have the option to reset virtual directories. You then use the wizard to re-create the required virtual directory.

You can also recreate the virtual directories using the Exchange Management Shell (EMS). The syntax required for each virtual directory is different, but fortunately, Microsoft outlines the needed syntax.

Note: If you remove a virtual directory using the EMS, you cannot create the new one using the EMC. Virtual directories can only be re-created in the EMC.

Although the above processes should work fine, you may still see an error message stating that the virtual directory has not been re-created.

Troubleshooting Exchange 2010 virtual directory re-creation: Check your scripts
If you’ve tried to re-create the virtual directories via the EMS, the first thing to check is that you’ve used the proper syntax. The EMS is very unforgiving, and the error message doesn’t always make clear what the problem is. Each virtual directory has its own syntax, so be aware of the variants for each.

Second, check your spelling. I don’t want to sound like your English teacher, but the EMS doesn’t come with a spell checker. Check spelling and punctuation twice, and then check it again.

To get a better idea of what’s working and what isn’t, try using the –verbose switch at the end of the EMS command. This will give you the detailed breakdown of the command processing rather than just the part that failed.

Troubleshooting Exchange 2010 virtual directory re-creation: Has the virtual directory been fully removed?
If you still encounter virtual directory re-creation problems after performing the normal EMS checks, it may be that the original virtual directory was not fully removed.

The only way to know for sure is to check the IIS Metabase. If you don’t already have it, you must Windows Server 2008 R2. However, it is not supported. In other words, if it does cause you problems, you won’t get help from Microsoft.

If you see entries for a virtual directory that you’ve tried to remove in the IIS Metabase, then rename them (to be on the safe side) and run the new virtual directory command again.

Another area to troubleshoot is the Application Running mode in IIS. If your IIS Application pools are set to allow you to create 32-bit applications on a 64-bit machine, then you will probably see all sorts of virtual directory difficulties once an Exchange server is installed.

To ensure that this is turned off, run the following command:

Cscript c:inetpubadminscriptsadsutil.vbs SET /w3svc/AppPools/Enable32BitAppOnWin64 False

Troubleshooting Exchange 2010 virtual directory recreation: Web.config file issues
When recreating the virtual directories, understand that this simply recreates the IIS/Exchange collaboration elements. It doesn’t recreate the installation folders that contain the virtual directory information. For example, if you’ve made changes to the web.config file and you’ve identified it as the reason that a virtual directory has stopped working, then recreating your virtual directory is not the answer.

Note: If you ever plan to make changes to the web.config file of any virtual directory, back it up first, even if a web.config.bak file exists.

If you run the virtual directory recreation and still have web.config problems, check the installation directory listed in the web.config file under the </AppSettings> header for the given virtual directory. From a standard installation, the install directories are listed as %ExchangeInstallationDirectory%.

Although this typically works fine, you may still be unable to get to the Exchange virtual directories after you have recreated the virtual directory. If you have enabled debugging in the web.config file, then the error page displayed explains that an Exchange component is missing.

In order to fix this, go into the web.config file and do a find and replace to the actual physical path to your exchange install files: Drive:Program filesMicrosoftExchange serverV14Client Access.

About these ads

Posted in Exchange | Tagged: , , , , , , | 1 Comment »

Seven ways to secure Exchange Server 2010 post deployment

Posted by Alin D on May 6, 2012

Many admins agree that it’s fairly simple to install Exchange Server 2010. However, the installation wizard doesn’t walk you through the tasks required to achieve a secure Exchange Server deployment. But you can use the following seven steps as a post-deployment checklist to ensure the security of Exchange Server 2010.

1. Install antivirus software for Exchange 2010

The first thing you should do after deploying Exchange Server 2010 is to make sure you have Exchange-aware antivirus software on each server. Microsoft recommends using Forefront Protection 2010 for Exchange Server but feel free to use any Exchange 2010-aware antivirus product.

2. Deploy a certificate to your Exchange 2010 client access server

Another key security precaution involves deploying an SSL certificate to your client access server (CAS). The CAS is configured to use a self-signed certificate by default. However, self-signed certificates are usually considered inadequate because they are issued by the Exchange server itself and not a trusted certificate authority (CA). Therefore, the certificate’s issuer cannot be verified in the same way it would be if you were using a commercial certificate.

3. Take steps to control spam in Exchange 2010

Ideally, your Exchange organization should be equipped with an edge transport server. The edge transport server is deployed in the perimeter network to control spam while hiding the back-end Exchange organization from the Internet.

That said, although Microsoft highly recommends using an edge transport server, it is often cost-prohibitive for smaller organizations. If you’re not using an edge transport server you must control spam at the hub transport level. One option is to install Exchange’s native antispam agents. To do so, open an Exchange Management Shell (EMS) session and enter the following commands:

./Install-AntispamAgents.ps1
Restart-Service MSExchangeTransport

Of course you also have the option to deploy a third-party antispam product.

4. Enable RPC encryption in Exchange 2010

When Microsoft created Exchange Server 2010, one of its main goals was to make the product inherently secure by default. Microsoft implemented a number of security mechanisms, one of which was to automatically use RPC encryption for MAPI connections.

Both Outlook 2007 and Outlook 2010 support RPC encryption, but Outlook 2003 does not. Previously, to make Outlook 2003 work correctly with Exchange 2010, you had to disable RPC encryption through a group policy setting.

The lack of support for RPC encryption in Outlook 2003 must have generated too many support calls, because Microsoft disabled RPC encryption in Exchange Server 2010 SP1. If you want your MAPI sessions encrypted, you must enable RPC encryption manually.

To do so, open the EMS and enter the following command:

Get-RPCClientAccess | Set-RPCClientAccess –EncryptionRequired $True

Verify that the setting has taken effect using this command:

Get-RPCClientAccess | FL Server, *Version, EncryptionRequired

5. Deploy Information Rights Management in Exchange 2010

It’s easy to think of Exchange Server security as the process of hardening your Exchange servers against attack. While this is certainly part of the process, the ultimate goal is to prevent the tampering or unauthorized disclosure of email messages.

One of the best ways to protect Exchange mail is to enable Information Rights Management (IRM). IRM lets you or your users control what message recipients can do with messages they receive from your organization. For example, you can prevent users from forwarding, modifying, printing, or copying and pasting email messages. You can also use IRM to protect supported file attachments.

6. Configure ActiveSync mailbox policies in Exchange 2010

If you plan on supporting mobile devices in your Exchange Server organization, ActiveSync mailbox policies are essential. You can use them to ensure that mobile devices adhere to your company’s security standards. For example, you can use ActiveSync mailbox policies to enforce password policies, enable or disable specific device hardware and to control whether or not attachments may be downloaded to mobile devices.

One setting that deserves special attention is the Allow Non-Provisionable Devices setting. If you select this option, you allow mobile devices to synchronize with Exchange even if those devices do not support all your ActiveSync Mailbox Policy settings.

It might seem like you should never allow non-provisionable devices, but it’s worth noting that the only mobile devices Microsoft considers fully provisionable are those running Windows Mobile 6.x; even Windows Phone 7 devices are not considered fully provisionable.

7. Run the Exchange Best Practices Analyzer

After you’ve finished securing Exchange 2010, run the Microsoft Exchange Best Practices Analyzer (ExBPA). It will help verify that your Exchange deployment adheres to Microsoft’s best practices as well as alert you to certain security settings that still need to be implemented or adjusted.

Posted in Exchange | Tagged: , , , , , , | Leave a Comment »

How to troubleshoot Exchange 2010 Management Console crashes

Posted by Alin D on March 17, 2012

Exchange Server 2010 is a complex product and there are a number of technical problems that can occur. Surprisingly, one of the most common issues admins encounter is Exchange 2010 Management Console failures. Let’s find out why the console may cease to function and how to fix it.

1. Connection problems

The Exchange Management Console (EMC) has changed a lot since Exchange Server 2007. In Exchange 2007 the console has relatively few dependencies. Things work much differently in Exchange 2010 though. Every EMC session is treated as a remote session, even if you’re opening the console locally on an Exchange 2010 server. If the console can’t connect to the “remote” Exchange server then you’ll probably receive an error message
.

Connection failures often cause the Exchange Management Console to break down.

 

The EMC is essentially a graphical front end to the Exchange Management Shell (EMS), which is built on PowerShell. Therefore, when you open the EMC, the console opens a remote PowerShell connection. There are three main mechanisms at work when this happens: Internet Information Services (IIS), WinRM and Web Services for Management (WS-Management).

To solve problems like the one above, first check to make sure that the Default Web Site is accessible on all of your Exchange servers. The error shown in Figure 1 was triggered when I opened the IIS Manager, selected the Default Web Site and clicked Stop.

Although stopping the Default Web Site can trigger an EMC failure, the console can also fail if the Default Web Site is running. If anything prevents the Default Web Site from being accessible, then it has the same effect on the EMC as stopping the site.

In order for the EMC to establish a remote PowerShell session, WinRM must be able to communicate with IIS over TCP Port 80. Therefore, if you have a firewall on, or in front of, your Exchange server that is blocking HTTP traffic, the firewall might be the source of the problem. Remember, it’s not just client access servers that must be able to receive HTTP traffic. All Exchange 2010 servers must be accessible to WinRM via TCP Port 80.

2. Site redirection problems

Site redirection is another common cause of an Exchange 2010 Management Console failure. Some administrators try to configure their client access server (CAS) so that any inbound HTTP requests are automatically redirected to the OWA virtual directory.

If done incorrectly, this type of redirection effectively prevents HTTP traffic from reaching the Default Web Site, resulting in an EMC failure. Forcing the redirection of HTTP traffic on your client access servers can also impact ActiveSync and Outlook Anywhere.

3. Authentication problems

The EMC can also break down as a result of an authentication failure. When a remote PowerShell session is established, IIS uses Kerberos to authenticate the connection. As strange as it may seem, Kerberos only functions properly if the PowerShell virtual directory treats it as a native module.

To test this, go to the IIS Manager and navigate to Sites -> Default Web Site -> PowerShell. Next, double-click the Modules icon, then scroll through the list of modules until you locate KERBAUTH. This module should point to C:Program FilesMicrosoft Exchange ServerBin and it should be listed as a Native module.

The Kerberos authentication module must be listed as Native

 

If the Kerberos Authentication module is listed as a Managed module rather than a Native module, it’s because the module is being directly used by the Default Web Site. If you select the Default Virtual Directory container and double-click the Modules icon, you should not see KERBAUTH listed.

If the module is listed, you must determine which virtual directories require the module. You must then remove the module from the Default Web Site and apply it directly to the virtual directories that require it. Exchange 2010 automatically adds the Kerberos Authentication module to the virtual directories where necessary. Therefore, you should only encounter this particular problem if the server is hosting a non-Exchange website that’s using Kerberos authentication.

As you can see, there are a number of potential causes for an EMC failure. If none of the techniques I’ve described correct the problem, check the bindings for the Default Web Site to make sure that the HTTP bindings have not been removed. The EMC can’t function if IIS only has bindings for HTTPS (SSL).

Posted in Exchange | Tagged: , , , , , , | Leave a Comment »

How to move data using PowerShell when migrate to Exchange 2010

Posted by Alin D on March 10, 2012

You’ve made the decision to migrate to Exchange Server 2010. After you’ve brought Exchange Server 2010 into your existing Exchange organization and properly prepared Active Directory, the next step is to move mailboxes, public folders and PST data from your old Exchange servers to your new Exchange 2010 servers. You’ll need PowerShell to accomplish these tasks.

Note: You can move content between mailbox servers using the graphical user interface, but it’s usually easier to use Exchange Management Shell commands because you can perform bulk moves using a single line of code.

Moving mailboxes to Exchange 2010 using PowerShell
In Exchange Server 2010, mailbox moves are performed using move requests. A move request requires the name of the mailbox being moved as well as the name of the target database. If you don’t specify a target database, Exchange will select one at random.

For example, if you wanted to move a mailbox named User1 to an Exchange 2010 database named DB1, you could use the following command:

New-MoveRequest –Identity User1 –TargetDatabase DB1

Now that you know how to move a single mailbox, a more efficient approach is to move allof the mailboxes from an entire mailbox database with a single command. For example, to move all of the mailboxes from DB1 to DB2, use the following command:

Get-Mailbox –Database DB1 | New-MoveRequest –TargetDatabase DB2

It’s also possible to create a detailed report of the moves after they’ve been completed. The report can be written to a text file or to a CSV file. To create a move report and write the output to a file named C:MOVE.LOG, enter the following command:

Get-MoveRequest | Get-MoveRequestStatistics | Select DisplayName, Status, TotalItemSize, TotalMailboxItemCount, BytesTransferred, ItemsTransferred | Out-File –FilePath “C:move.log”

If you don’t want to wait to check the status of the move, you can also generate a report to find out how it is progressing. If you want to see how far along the move is, use the following command:

Get-MoveRequest | Get-MoveRequestStatistics | Select DisplayName, Status, PercentComplete, BytesTransferred, ItemsTransferred | Out-File –FilePath “C:move.log”

When all your mailbox moves complete, you must terminate the move request. If you don’t, you won’t be able to move the mailboxes again should the need arise. To terminate a move request, use the Get-MoveRequest | Remove-MoveRequest command.

Moving public folders to Exchange 2010 using PowerShell
Public folders are not a requirement in Exchange Server 2010 unless you plan on having an Exchange 2010 mailbox server that supports clients running Outlook 2003 or earlier. That said, if you have public folders on your legacy Exchange servers that contain useful data, you can move them to Exchange 2010 using PowerShell.

To move all of the public folder replicas from one Exchange server to the other, open the Exchange Management Shell, and enter the following commands:

Set-ExecutionPolicy Unrestricted
CD
CD “Program FilesMicrosoftExchange ServerV14Scripts”
./MoveAllReplicas.ps1 –Server <old server name> -NewServer <new server name>

When the process completes, set the execution policy back to RemoteSigned by entering theSet-ExecutionPolicy RemoteSigned command.

Importing PST files into Exchange 2010 using PowerShell
Exchange Server 2010 is the first version of Exchange to support personal archive mailboxes. Many organizations place archive mailboxes onto dedicated mailbox servers that are equipped with low-cost storage, so that user archives do not affect the performance of the primary user mailboxes.

Archive mailboxes offer a great alternative to PST files, and many organizations have begun moving PST file contents to archive mailboxes as a part of the migration process. Note, however, that this method works only for Exchange 2010 SP1. The RTM release of Exchange 2010 used a different PowerShell cmdlet that was buggy. You should also know that this cmdlet doesn’t create the archive mailboxes; so make sure that the archive mailboxes actually exist before using it.

To import a PST file into an archive mailbox, use the New-MailboxImportRequest –FilePath <the path to the PST file> -Mailbox <mailbox name> -IsArchive cmdlet.

Posted in Exchange | Tagged: , , | Leave a Comment »

Exchange Server virtualization improved in vSphere 5

Posted by Alin D on January 23, 2012

There are many new features in VMware vSphere 5 that supercharge performance, storage and quality-of-service of virtualized servers. Some of the improvements are particularly beneficial for virtualized Exchange servers.

Out of the 140-plus new features in vSphere 5, here are five that offer the most value to Exchange Server virtualization:

Storage Distributed Resource Scheduler

One of the most impressive features in vSphere 5 is Storage Distributed Resource Scheduler (SDRS). A traditional VMware Distributed Resource Scheduler (DRS) automatically places virtual machines (VM) onto servers with low CPU and RAM resource utilization to support the VM requirements. DRS also automatically load balances VMs by dynamically moving them from one host to another if they aren’t receiving necessary resources.

The new SDRS tool performs both these very powerful functions, but for virtual storage. In other words, SDRS:

  • Places VM disk files onto shared storage that has the necessary space and storage latency;
  • Balances VM disk files across shared storage to ensure optimal storage performance; and
  • Balances VM disk files across shared storage to ensure the VM has the space it needs.

If your VM’s data store runs out of space, SDRS moves the VM disk file to another data store that contains the necessary space. Additionally, if a VM’s data store isn’t performing particularly well, SDRS moves the VM disk file to the data store that offers the best performance.

In vSphere 5, VMware also introduces the concept of the “data store cluster” which is simply a group of data stores. You can use data store clusters with or without SDRS.

Exchange servers need proper storage I/O to perform optimally. SDRS automatically resolves storage I/O and storage capacity issues, preventing slowness and outages for your Exchange users.

 VMware vSphere 5 virtual machine file system and VM scalability enhancements

The latest version of vSphere also offers increased scalability for VMs and the virtual machine file system (VMFS). Here are some specific improvements:

  • 512 virtual machines per host;
  • Up to 160 CPU threads (logical pCPUs) per host;
  • Up to 2 TB of RAM per host;
  • Up to 32 vCPUs per VM;
  • Up to 1 TB of RAM per VM; and
  • Up to 2 TB for new data stores.

These enhancements help when your Exchange VMs grow and also when you need to create large files on the VMFS.

 The vSphere 5 Storage Appliance

VMware also introduces the concept of the vSphere Storage Appliance (VSA) in vSphere 5, which is essentially a virtual network attached storage (NAS) option. It is fully supported by VMware for all advanced vSphere features like vMotion, DRS, VMware High Availability (VMHA) and even Site Recovery Manager (SRM). The downside is that you must purchase it separately.

VSA uses local storage from either two or three VMware ESXi servers, plus vCenter. These servers must be identical and fresh installs of ESXi. These servers also can’t have any VMs running on them — not even vCenter. The local storage is presented by the VSA as a network file system NAS share.

VSA is meant for small- to medium-sized businesses that don’t already have a storage area network (SAN) or NAS and use VMware for server virtualization. The VSA is a great fit for remote office/branch office locations where it’s hard to justify the cost of a NAS.

The VSA does offer a unique benefit in that if an ESXi host is lost, VMs running across the VSA keep working without downtime (Figure 1). Thus, VSA offers better high availability and redundancy than a hardware-based NAS/SAN at a much lower price than redundant NAS/SAN.

How the vSphere 5 storage appliance works

 

So, how does VSA help virtualized Exchange infrastructures? Well, I’m not sure I’d recommend the new VSA as the single NAS/SAN in a large datacenter with hundreds of VMs – including Exchange – hitting it.

But the VSA is ideal for branch offices of a larger company that require a local Exchange infrastructure. The VSA helps you bypass dedicated NAS hardware, while still achieving high availability, making it a strong option for shared storage.

VMware vSphere replication

Before vSphere 5, you could only protect virtual infrastructures using either VMware Site Recovery Manager (SRM) with a hardware-based SAN or an application-specific recovery tool. Both options were poor value for your investment. You either had to purchase two hardware-based SANs with replication — one for each datacenter — or spend a lot to protect a single application like Exchange Server.

With vSphere 5 and SRM5, VMware announced the option for “host-based replication.” This means that an ESXi server replicates directly to another ESXi server at a backup datacenter, eliminating the need for two hardware-based SANs with replication.

Alternatively, you can replicate from a hardware-based SAN that you may have already invested in to a different SAN at a backup site. This is a huge cost savings for all types of companies because it allows disaster recovery to happen on a per-VM and per-application basis.

VMware sells the SRM5 host-based replication option for under $200 per VM with a minimum of 25 VMs; that translates out to about $5,000. That’s a much better value than the other options.

As you can see, this has the potential to tremendously reduce the cost of protecting virtualized Exchange servers with vSphere 4.1, or even physical Exchange servers.

The vSphere 5 vCenter Server Appliance (vCSA) and vSphere Web Client

My new favorites in vSphere 5 are the vCenter Server Appliance and the new vSphere Web Client.

The vCenter Server Appliance (vCSA) is a virtual appliance you can import into your infrastructure to get vCenter up and running fast. Besides saving time on the Windows install, database install and vCenter application install, vCSA saves money because you don’t have to buy a another Windows Server license.

Not only is it free with all vSphere 5 licenses, but it also enables the new vSphere Web Client by default; you don’t have to install anything. While the vSphere Web Client doesn’t do everything that the vSphere Windows client does, it does do about 80% of what you will need so it’s a nice option for typical day-to-day virtualization admin tasks.

 A look at the VMware vSphere 5 Web Client

 

VMware said that the vCSA (virtual Linux-based vCenter appliance) and the vSphere Web Client are the direction they are going in the future so we might as well start learning about these new options, now.

As you can see, it’s a good idea to use vSphere 5 for Exchange Server virtualization because it offers innovative features, better scalability, easy administration and the best disaster recovery options. You can learn more about vSphere 5 here.

Posted in Exchange | Tagged: , , , , , , | Leave a Comment »

Exchange Server 2010 Service Pack 2 contains new features geared toward the cloud and Office 365

Posted by Alin D on December 12, 2011

Exchange Server 2010 Service Pack 2 launched this week with new features that bridge Exchange shops to the cloud. It also brings a new address book policies feature and Outlook Web Access improvements.

Microsoft gave customers a glimpse of some Exchange Server 2010 Service Pack 2 features back in May and delivered on new features including the Hybrid Configuration Wizard, which simplifies the process of creating a hybrid on-premises and cloud environment.

Previously, it was difficult to tie an on-premises Exchange Server 2010 environment to Microsoft’s cloud-based email and collaboration suite, Office 365. With the Hybrid Configuration Wizard, IT pros can create a hybrid Exchange 2010/Office 365 environment in just a few steps — for short- or long-term coexistence.

The new wizard tool provides a rich coexistence between Exchange Server and Office 365 that is necessary for multi-mailbox searches of both on-premises and hosted mailboxes. The tool also facilitates archiving in the cloud, where IT pros can place users’ personal archives in Office 365 while keeping all other mail on-premises.

While the new tool makes it easier to combine on-premises and cloud Exchange environments, Exchange shops shouldn’t look at the Hybrid Configuration Wizard as an “easy button” to the cloud.

“[The hybrid wizard] streamlines the process,” said Mike Crowley, an Exchange MVP enterprise infrastructure architect at Planet Technologies Inc. “But it doesn’t give you a pass for not paying attention.”

More Exchange 2010 SP2 features
While the hybrid wizard tool aims squarely at companies considering Office 365, Microsoft added new address book policies that aid large on-premises Exchange deployments and hosted Exchange setups. With address book policies, you can segment global address lists (GALs) so that users cannot see every user in an Exchange organization.

“Address book policies are great for privacy because users should only be able to see who management wants them to see,” said Rob Sanfilippo, an Exchange analyst with Directions on Microsoft, an independent analysis firm based in Kirkland, Wash.

Unfortunately, address book policies also require an Active Directory schema update. Admins hesitate to deploy a service pack that requires such an update, but they shouldn’t let fears block deployments, Sanfilippo said.

Exchange 2010 SP2 also includes two Outlook Web App improvements in OWA Mini and cross-site silent redirection. OWA Mini is geared toward users that may not have large screens on their devices and/or don’t have ActiveSync-enabled phones. Cross-site silent redirection improves the single sign-on experience.

You can download Exchange Server 2010 SP2 from the Microsoft Download Center. Additionally, companies that run unified messaging should download the Exchange 2010 SP2 language packs.

Posted in Exchange | Tagged: , , , , , , | Leave a Comment »

ActiveSync management from the command line in Exchange 2010 SP1

Posted by Alin D on December 4, 2011

Microsoft’s recent disclosure that PowerShell will play a larger role in server management gives Exchange administrators another reason to familiarize themselves with the command line. Consider the growing number of mobile and remote users and you’ll see why it helps to master the commands necessary to manage ActiveSync.

The Exchange Management Shell commands discussed here are intended for use with Exchange 2010 SP1. Many of these commands exist in earlier versions of Exchange, but in certain cases, Microsoft has changed the syntax.

Creating a new ActiveSync mailbox policy via the Exchange Management Shell
Creating new ActiveSync mailbox policies from the command line may seem pointless to some. After all, many administrators create a single ActiveSync mailbox policy and it’s all they need. However, it’s important to realize there are many different mobiles devices out there and they all have different capabilities.

You can achieve a more granular level of control if you create a separate ActiveSync mailbox policy for each device type, and then base each policy around an individual device’s capabilities. For example, you can create one policy for Windows phones and a separate policy for iPhones.

To create a new ActiveSync mailbox policy, use the New-ActiveSyncMailboxPolicy command and append the –Name parameter. You must also assign the new policy a descriptive name. Your command will look similar to this:

New-ActiveSyncMailboxPolicy –Name ‘<policy name>’

After you create an ActiveSync mailbox policy, you must assign policy values. There are a number of parameters you can append to this command depending on how you’d like to configure the policy. Here are some commonly used parameters:

AllowNonProvisionableDevices
DevicePasswordEnabled
AlphanumericDevicePasswordRequired
MaxInactivityTimeDeviceLock
PasswordRecoveryEnabled
RequireDeviceEncryption
AttachmentsEnabled
AllowSimpleDevicePassword

Assign either a $True or $False value to all of these parameters. Other parameters require numerical values, while the Unlimited and $Null values can take the place of numbers. Here are some examples:

MinDevicePasswordLength $Null
DevicePasswordExpiration ‘Unlimited’
DevicePasswordHistory ‘0’

Below, observe that I’ve created an ActiveSync mailbox policy with all the aforementioned parameters:

New-ActiveSyncMailboxPolicy –Name ‘<policy name>’ -AllowNonProvisionableDevices $False –DevicePasswordEnabled $False –AlphanumericDevicePasswordRequired $False –MaxInactivityTimeDeviceLock $False –PasswordRecoveryEnabled $False –RequireDeviceEncryption $True –AttachmentsEnabled $True –AllowSimpleDevicePassword $True -MinDevicePasswordLength $Null -DevicePasswordExpiration ‘unlimited’ -DevicePasswordHistory ‘0’

Adding a user to an ActiveSync mailbox policy via the Exchange Management Shell
Just as you can create an ActiveSync mailbox policy from the command line, you can also add users to the policy via an Exchange Management Shell (EMS) command:

Set-CASMailbox <user name> -ActiveSyncMailboxPolicy(Get-ActiveSyncMailboxPolicy “<policy name>”).Identity

For example, if you want to add a user named JaneD to an ActiveSync mailbox policy namedWindowsPhone, you can use the following command:

Set-CASMailbox JaneD –ActiveSyncMailboxPolicy (Get-ActiveSyncMailboxPolicy “WindowsPhone”).Identity

Retrieve mobile device usage statistics via the Exchange Management Shell
You can use the Get-ActiveSyncDeviceStatistics command in two ways. For one, you can use it to retrieve ActiveSync usage statistics for an individual user. To do so, use the following command:

Get-ActiveSyncDeviceStatistics –Identity <user name>

You can also use this command to create a report detailing the end users in your organization that have devices linked to their Exchange mailboxes. You can then display usage statistics for those devices. This command’s syntax is tricky because you must apply a filter to prevent client access server-related statistics from displaying alongside the mobile device usage statistics. To do so, use the following command:

Get-CASMailbox –Filter {HasActiveSyncDevicePartnership –eq $true and –not DisplayName –Like “CAS_(*”} | Get-Mailbox | ForEach { Get-ActiveSyncDeviceStatistics –Mailbox $_}

View which mobile devices are in use via the Exchange Management Shell
To find out how many devices a user has, use the Get-ActiveSyncDevice command. The reasons to use this command are similar to those of the Get-ActiveSyncDeviceStatisticscommand. For example, to view the devices registered to an individual user, use the following command:

Get-ActiveSyncDevice –Identity <user name>

To view all devices for all users in your Exchange organization, use the following command:

Get-CASMailbox –Filter {HasActiveSyncDevicePartnership –eq $true and –not DisplayName –Like “CAS_(*”} | Get-Mailbox | ForEach { Get-ActiveSyncDevice –Mailbox $_}

Posted in Exchange | Tagged: , , , , , , | Leave a Comment »

Run Exchange 2010 backup or skip this

Posted by Alin D on October 29, 2011

When Exchange Server 2010 RTM hit, some IT pros suggested that database availability groups in Exchange 2010 make traditional backups unnecessary.

I initially scoffed at the idea. However, Exchange 2010 has been available for a while and the idea of a “backup-less” Exchange server makes sense in some environments.

The concept behind ‘backup-less’ Exchange
A backup is nothing more than a point-in-time copy of your data. It is this deceptively simple definition that led to the idea of running Exchange 2010 without backups.

Some say running Exchange 2010 without backups is safe because of the way database availability groups (DAGs) work. A single DAG can contain up to 16 mailbox servers and an individual mailbox database can be replicated to any combination of mailbox servers within the DAG.

The argument against backing up Exchange 2010 boils down to how many copies of data you really need. If you already have 16 replicas of a mailbox database, do you really need a seventeenth copy as backup?

Important Exchange backup considerations
While the argument against backing up Exchange 2010 in environments with DAGs sounds logical, there are a number of important factors to consider before ditching your backup system.

  • DAG size
    While you can include up to 16 mailbox servers in a DAG, you can also create very small groups. Therefore, you must consider the size of your DAG before abandoning backups. Microsoft recommends that you only consider going without a backup if you have three or more mailbox servers in your DAG.
  • Transaction logs
    Typically, when you back up an Exchange mailbox server, the contents of transaction logs are committed to the database as part of the backup process. If you never perform a backup, the transaction logs accumulate until the volume runs out of disk space. Because of this, organizations that do not back up Exchange 2010 must enable circular logging to prevent log file accumulation.
  • Offsite storage
    It’s easy to think of a backup-less Exchange organization in the same way as a disk-based backup solution because database contents are replicated to other servers.However, organizations that depend on disk-based backups usually adopt a disk-to-disk-to-tape solution where the disk-based backups are periodically copied to tape and stored offsite. If the data center burns down, the backups remain safe.

    If you’re considering operating Exchange without backups, it’s smart to place a few DAG members in a remote data center. That way, your data remains protected even if something happens to your primary data center.

  • Point-in-time recovery
    The biggest disadvantage to running Exchange 2010 without backups is that you lose the option of accurate point-in-time recoveries. For example, imagine that your entire company became infected with a virus.In this situation, you could restore a backup that was made prior to the infection, rather than trying to remove every infected message from your mailbox database. This is simple with a traditional backup, but isn’t practical if you go without.

    Notice that I didn’t say that it’s impossible to perform a point-in-time recovery without a backup. Microsoft does let you create lagged database copies that log files are not immediately replayed on. That way, if you need to revert to a particular point in time, you can activate a lagged copy.

    The problem is that there’s a lot of guess work involved in the process. You must know exactly when the problem began in order to get rid of all of the transaction logs that were created after the problem occurred. This is accomplished by replaying the transaction logs that were created prior to the problem. Unfortunately, there isn’t an easy way to figure out which transaction logs should be used and which should be deleted.

    As you can see, it’s perfectly feasible to run Exchange 2010 without traditional backups in certain situations. That said, I advise backing up Exchange as you always have. If an unforeseen set of circumstances leads to data loss, you won’t have to explain to your boss or management that you don’t have backups.

Posted in Exchange | Tagged: , , , , , , | Leave a Comment »

Server load balancing in Exchange 2010 hub transport

Posted by Alin D on September 26, 2011

Microsoft encourages failover clustering to provide fault tolerance and redundancy for Exchange Server. However, neither the client access server nor the hub transport server roles support failover clustering in Exchange 2010 — only mailbox servers may be clustered.

To provide fault tolerance and redundancy for your hub transport servers, you must deploy one or more additional hub transport servers. When you do, Exchange 2010 automatically distributes the workload across your hub transport servers. This way, you don’t have to worry about building a cluster or configuring Exchange to use the new server.

While providing redundancy for the hub transport server role in Exchange 2010 is fairly simple, there are a couple of important factors to remember when it comes to effective load balancing.

Each mailbox server requires a hub transport server


The hub transport server resides at the Active Directory-site level. This means that every Active Directory (AD) site that contains an Exchange mailbox server also needs at least one hub transport server. You can’t set up a single hub transport server and expect it to service a multi-site.

Exchange Server deployment.

Because the hub transport server functions at the AD-site level, redundancy and fault tolerance must also occur there. Deploying redundant hub transport servers help provide load balancing and fault tolerance for a single site, not the entire Exchange Server organization.

The importance of Exchange Server 2010 Service Pack 1


The other important thing that you need to know about protecting the hub transport server role is that if you’re using Exchange Server 2010 and have hub transport servers in multiple sites, Exchange 2010 Service Pack 1 (SP1) is essential. If you haven’t installed Exchange 2010 SP1, a hub transport server failure will result in uneven workload distributions.

When Exchange 2010 routes messages to another AD site, it uses a technique similar to domain name system (DNS) round robin to distribute the load among the hub transport servers in the remote site. For example, if a remote site contains five hub transport servers, each server receives approximately 20% of the messages sent from the local site.

With that in mind, imagine that one of the five hub transport servers fails. The hub transport servers in the local site are completely unaware of the failure in the remote site. Therefore, the servers continue distributing the workload to all the remote hub transport servers. The connections to the offline hub transport server fail, but once the failure is detected, Exchange routes the messages to the next hub transport server.

The problem here is that the next hub transport server in line must take on the failed server’s workload in addition to its own. This behavior is normal for sites with only two hub transport servers, but for sites with three or more hub transport servers, it results in uneven load balancing. Consider our example: If a failure occurred in a site with five hub transport servers, one of the remaining servers would need to handle 40% of the total workload, while the three remaining servers still received only 20% of the total workload.

Exchange 2010 SP1 is essential because it includes a feature called the Healthy Server Selector, which tracks which Exchange servers are available. If a hub transport server in a remote site fails, the Healthy Server Selector discovers the failure and prevents the local hub transport servers from sending messages to the failed server until it comes back online. This helps Exchange ensure that workloads are evenly distributed among the remaining hub transport servers.

Posted in Exchange | Tagged: , , , , , , | Leave a Comment »

Exchange Server 2010 Shadow Redundancy

Posted by Alin D on August 23, 2011

One of the most significant architectural changes that Microsoft made in Exchange Server 2007 was the introduction of the hub transport server. Microsoft designed the hub transport server so that all messages had to pass through a centralized transport pipeline, opening the door for transport rules and transport-level archiving. However, it also made Exchange Server 2007 vulnerable to hub transport failures.

Exchange Server 2007 hub transport servers use a database that acts as a message queue. As soon as a message is sent to the next hop , the message is deleted from the hub transport database. Because there are no safeguards around the hub transport database, message loss can occur if a hub transport server fails.

Microsoft built safeguards for clustered mailbox servers; when a message is sent to a recipient whose mailbox resides on a clustered mailbox server, a copy of the message is placed into a transport dumpster on the hub transport server. If one of the cluster nodes fails, recently sent items can be retransmitted so that messages are not lost during failover.

Although the transport dumpster protects against message loss, it’s only protects mailboxes that reside on a clustered mailbox server. The transport dumpster also does not protect against message loss for messages flowing between the hub transport server and an edge transport server.

Shadow Redundancy makes hub transport servers more resilient against message loss. In Exchange Server 2010, hub transport servers still use a transport database as a message queue. Exchange Server 2007 deleted messages from the database as soon as they were sent to the next hop; however, Shadow Redundancy keeps messages in the database until Exchange confirms that they were been delivered. This way, if message delivery fails, messages could be retransmitted.

Although the basic premise behind Shadow Redundancy is simple, the actual mechanics used are not. Previous versions of Exchange Server were not designed to verify message delivery. Microsoft has extended SMTP service so that SMTP hosts can negotiate Shadow Redundancy support in Exchange Server 2010.

This approach enables hub transport redundancy. Although no version of Exchange supports clustering hub transport servers, Shadow Redundancy produces the same result. Simply put, the failure of a hub transport server no longer leads to message loss.

If redundant hub transport servers exist, messages will be automatically rerouted through one of the remaining hub transport servers. The best part about this is that Exchange Server does not require that copies of every message be sent to each hub transport server in case of failure. This is possible because each server that a message passes through retains its own shadow queue.

For example, imagine a user with a mailbox on Server 1 sends a message to a user whose mailbox is on Server 2. The sender composes the message in Outlook and its sent to his outbox on Server 1. Server 1 places a copy of the message into a shadow queue, and then sends the message to the hub transport server. Let’s assume that the hub transport server receives the message, but fails before it can confirm that the message has been delivered to the recipient’s mailbox on Server 2.

Server 1 will eventually reach a timeout threshold and realize that it received no delivery confirmation. Server 1 — which still has a copy of the message in its shadow queue — attempts to send the message again. Since the original hub transport server used is offline, the message is sent through a different hub transport server. This time, Server 2 confirms receipt of the message. Server 1 eventually receives the confirmation and the message is removed from its shadow queue.


 

Posted in Exchange | Tagged: , , , | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.

Join 505 other followers

%d bloggers like this: