One of the things that I get a lot of questions about when I start leading people down the CLI path is whether or not the Exchange Management Shell is just PowerShell with a fancier icon. We frequently open the EMS in order to perform certain managerial tasks in Exchange, and we hear more and more coming out of Redmond regarding PowerShell. So let’s discuss it.

As it turns out, the Exchange Management Shell is PowerShell (big surprise there) but it’s a more specialized environment than you get when simply running PowerShell.exe, with a lot of specific settings to make it talk to Exchange. In this post, we’ll go over the differences, and when you want to use one or the other.

The Exchange Management Shell (EMS) uses PowerShell as its base, but it expands upon PowerShell in a number of ways. Many of these you could do yourself, either manually by entering specific commands, or by automating those tasks in your profile. When you launch the EMS, you connect to a remote session on an Exchange server using Windows Remote Management 2.0 (WinRM). Even if you are running the EMS on the only Exchange server in your environment, you connect to that WRM. The only exception to this is the Edge Transport server. Because it is a standalone role, when you launch the Exchange Management Shell, you connect to the local server only, much like you did in Exchange 2007.

When you connect, authentication checks create a session for you with access to the cmdlets and parameters you have permission to run based on your assigned management roles. The cmdlets are contained within three snap-ins:

1. Microsoft.Exchange.Management.PowerShell.E2010
2. Microsoft.Exchange.Management.PowerShell.Setup
3. Microsoft.Exchange.Management.Powershell.Support

You could load those into a PowerShell session using the Add-PsSnapin command but there are still differences between the two environments. Launching PowerShell and adding the snapins would give you access to the cmdlets, but first, you would still need to connect your session to the WinRM instance running on the Exchange server. You would also be running all of the available commands as cmdlets. When you launch the EMS, you run these as functions.

When it comes to writing scripts, the good news is that because EMS is built on top of PowerShell, there’s no real difference when it comes to scripting and using the EMS. Some of the system variables do not work fully in the EMS though, so if you are going to write a script that uses a system variable, you are better off adding the snap-ins to PowerShell.

While most Exchange admins tend to use the remote desktop client to connect to an Exchange Server, when they want to run EMS commands that is not necessary. If you are running a 64 bit desktop, you can install the Exchange Management Tools on your workstation from the Exchange installer. Users with the –RemotePowerShellEnabled attribute set to true, and assigned to at least one Exchange management role, will be able to run the EMS on their workstation and manage Exchange.

In future posts, we’ll start to dig deeper into the EMS and explore just how powerful and useful this administrative interface is.

Exchange Management Shell vs PowerShell

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Just recently, a new industry consortium made up of email providers, financial institutions, social media properties and security providers put their heads together and came up with the DMARC (Domain based Message Authentication, Reporting and Conformance) specification.

With a goal of setting up a collaborative effort to help organizations recognize and fight spoofed emails, spam, and phishing attempts, this group is relying on the deployment of the Sender Policy Framework and DomainKeys Identified Mail to complement existing anti-spam solutions.

With industry leaders like Google, Microsoft, PayPal and Bank of America already signed on, along with 11 other companies, DMARC’s work is certain to make a splash in the IT world.

To better help IT departments understand what DMARC is trying to do, and better prepare them to make a decision regarding DMARC, let’s take a little time and refresh our memory on SPF and DKIM.

Sender Policy Framework

One of the major flaws in the Simple Mail Transfer Protocol is that is allows any computer to send an email using a forged email address. For example, anyone exploiting SMTP could send a spoofed email from their computer at home and make it look like it was coming from a bank.

To address this major flaw in SMTP’s security, the Sender Policy Framework was created in 2003 by Meng Weng Wong. Using special DNS records, the owner of a domain has the ability to specify which computers are allowed to send email messages with the sender address in the specific domain.

Should an unauthorized computer attempt to send a message from the domain in question the SMTP server rejects the sender and the unauthorized computer will receive a rejection message.

SPF is not without vulnerabilities though. Spoofing the mail header information such as From or Sender is not something that SPF helps to protect against. It is also open to what is known as a wide mask vulnerability where spammers specify a wide mask of valid server addresses in hope that spam from their botnets become SPF valid and pass through spam filters.

DomainKeys Identified Mail

DKIM came about by merging the DomainKeys and Identified Internet Mail standards with the purpose of associating a domain name to an email message through a digital signature that can be validated by the recipient.

The signer attaches the digital signature to the message being sent using a private key. A verifier that receives the message then relies on the public key to validate the legitimacy of the signature.

So if an email arrives in a person’s inbox from their bank, and their bank uses DKIM then they can feel confident that the message did in fact come from their bank.

If a spammer tries to send a phishing email to the same person and claims to be a representative of the same bank, the message will be rejected and quarantined by the server – never showing up to the intended recipient.

Flaws found in DKIM include the ability to forward a verified message with the content having been modified. Since SPF does not allow for this, it is common to see DKIM and SPF combined.

DKIM is also known to be resource intensive as a result of the cryptographic checksums that validate the digital signature.

SPF, DKIM and DMARC

According to DMARC.org, DKIM and SPF relate to their specification in the following ways:

DomainKeys Identified Mail (DKIM)

• DKIM provides a method for validating a domain name identity that is associated with a message through cryptographic authentication.
• DMARC uses DKIM results as one method (SPF being the other) for receivers to check email./li>

Sender Policy Framework (SPF)

• SPF provides a method for validating the envelope sender domain identity that is associated with a message through path-based authentication.
• DMARC uses SPF results as one method (DKIM being the other) for receivers to check email.

Using the DMARC specification, member organizations can rely on the collaborative efforts of the group to share resources so that spoofed emails can be easily spotted and the amount of resources used in the process can be reduced.

Additionally, they are calling for email senders to sign 100% of their outgoing messages to insure the validity of emails sent.

Get Ready for DMARC – A Review of SPF and DKIM

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Often Exchange administrators will receive escalated help desk tickets from users complaining that Exchange is “slow” and demanding resolution. These sorts of tickets can be extremely challenging to work, since the subjective nature of slowness is often combined with an inability to replicate the problem, or the problem is intermittent. The Exchange admin can take a look at the server(s) for high CPU utilization, low memory conditions, disk and network queue lengths exceeding the norm, and finding nothing, shrug it back off to the desktop support team as a client issue.

While it is often a client issue, there are several places between Outlook and a user’s mailbox that can cause intermittent slowness, and are fair to call networking bottlenecks. In a six part series of articles, we’ll look at how Exchange interacts on the network with various other services to help you identify network issues, and troubleshoot them when they occur.

In many cases, troubleshooting Exchange network bottlenecks will require a network trace, and may also require performance monitor counters. This series of articles will talk about both of those in general terms; how to use NetMon or Wireshark, and PerfMon are out of scope. In Part 4 of this series, we’re going to look at the humble physical layer (DoD, not OSI) and discuss troubleshooting NICs.

NICs

We’re now down where the rubber meets the road, that is, where the packets meet the wire. Your Network Interface Cards can be the most important part of the entire network connectivity between client process and server process, and are also the most commonly overlooked aspect of the entire communications channel. I’ve seen many a case where Exchange network performance issues came down to problems with the NIC, but days had gone by troubleshooting the problem, or weeks just accepting the poor performance, before anyone thought to look at the NICs. If the NICs aren’t happy, ain’t nobody happy so let’s make sure those NICs smile.

The differences between the various physical connections are beyond the scope of this article, but the recommendations and troubleshooting suggestions in this article should apply equally to all types of NIC, whether copper or fibre based, and whether physical or virtual. Let’s start with some best practices for connecting up all your servers and clients:

Use quality NICs

There are times to save money, and there are times to spend the extra for the best, and as far as Exchange servers are concerned, you cannot go wrong spending a little extra on the higher quality NICs. Single port or multi-port, specific name brand not as important, but don’t buy the cheap one off NICs or limit yourself to what is built-in to your server.

Use good cables

I take pride in my ability to “roll my own” cables (Ethernet, not fibre-optic) and I also know that name-brand cables can cost a fortune, but here again is where you don’t want to take any chances. All of your drop cables should be commercially made, but at the same time, don’t assume that because they are, they are faultless. Make it a habit to test all cables early in the troubleshooting process if not at time of install.

Use quality, managed switches

Inexpensive unmanaged switches are good for home use, or to provide last minute patches in a meeting room without wireless, but have no place in a datacenter. Make sure all your servers directly connect to managed switches that can provide you details and statistics about the physical connection.

With that out of the way, now we’ll move on to some more best practices that should also be the second steps you take on the server when troubleshooting connectivity issues, right after reseating all the cables.

Hardware Drivers

Make absolutely certain you are running the latest hardware drivers. Check the vendor site, and read the documentation for any known issues that might correlate to your problem, but unless there is something contraindicated in that documentation, make sure you have the latest supported drivers. If you do though, consider downgrading one rev just in case you have encountered a new bug.

Firmware

Don’t just stop at the software drivers for your NICs, make sure you have the latest firmware installed as well.

TCPIP.SYS

Check the Microsoft operating system drivers for your specific platform, and if you are not running the latest TCPIP driver, upgrade immediately. I have personally seen dozens of problems magically disappear just by catching up on patches. Of course, I do recommend staying current on all patches, but this is one that should have no exceptions.

Teaming

More connectivity problems have been “solved” by “breaking the team” than any other single fix in history. If you have having network connectivity problems and are using network teaming, break the team and see if the problem goes away. Do this early on, as it is a quick thing to check, and to put back if that is not the problem. Odds are that it is, and in that case, you need to troubleshoot network teaming, not Exchange networking. The solution will usually be with updating drivers, fixing a problem with your configuration, or something on the switch.

Receive Side Scaling and ToE

If your multi-processor Exchange server is slamming one CPU(or core) and the rest are sitting idle, it’s a good bet you don’t have RSS enabled. RSS lets your server balance NIC interrupts across all the CPUs, which leads to better overall performance. It’s on by default in 2008 and 2008R2, but might have been turned off by another admin. If you see high CPU on only one processor, check with this command.

netsh interface tcp show global

If Receive-side Scalaing state shows as disabled, you’ve found the culprit.

That same command will also show you the status of TCP Chimney Offload, or ToE. With compatible NICs, ToE can provide much better throughput on large file transfers (like database replication for DAGs, mailbox moves, etc.) and reduced CPU utilization. With it off, those operations will take much longer, have lower throughput, and cause higher CPU utilization. 2008 disables ToE by default, while 2008 R2 uses an automatic setting. If your NICs support ToE, make sure you are using it by enabling it (if necessary) in the O/S, and then setting the advanced properties of the NIC to use it.

Using Hardware Load Balancers

The biggest challenge to troubleshooting load balanced servers is that the problem usually will manifest itself as intermittent, or isolated to a single client or subnet. If load balancers are in the mix, test from your machine, but test against the VIP and against each physical server one by one. If you cannot reproduce the problem, try the same process from the client. This may be one time where you have to use a HOSTS file to trick the client into connecting to each server one by one. If you don’t have admin access to the hardware load balancer, get on with that admin to do your tests so they can view realtime logs to see if anything stands out.

The Microsoft Network Load Balancing Service

If you are trying to load balance Exchange servers and are running into problems using software load balancing, my money is on the problem being in your switch configuration, and not with the MS NLB service. The easy test is to move the VIP to one of the servers, validate that everything works, and then move the VIP to the other and validate again. If it works without NLB in the mix, then it is not Exchange you should be looking at. MS NLB works great, though it is limited to IP based affinity and not port based, but there are so many ways the switch and/or router that your server connects to can screw up NLB, I’ll frequently recommend against using it unless I can directly manage the switches myself, or I know the person who does and that he or she understands their side of making NLB work.

See  http://technet.microsoft.com/en-us/library/ff625247.aspx for some more tips on MS NBL, and if you are using VMware to virtualize your servers, see this article for specific settings in VMware. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007371

Coming up next

In Part 5, we will look at the issues that can cause Exchange problems when making RPC calls, and how to troubleshoot those problems. Here’s a rundown of the six parts in this series. We’ll update with live links as each part is published over the next several weeks.

1. Introduction and DNS
2. Active Directory
3. Firewalls
4. NICs (this post)
5. RPCs
6. Client side issues

Troubleshooting Exchange Networking: NICs (Part 4)

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

According to most reports, the amount of email spam is diminishing.

Experts credit the takedown of massive botnets like Rustock, a more educated user base and advancements in spam fighting technologies for this trend. However, even though one of the most annoying, and troublesome, threats to email accounts is on a downswing it doesn’t mean for one second that email is no longer a part of the IT infrastructure that is vulnerable to threats.

Understanding the different ways cyber criminals and script kiddies can use vulnerabilities in email clients and servers to attack a system will help any email administrator keep email services running smoothly, and the entire infrastructure safe from a great number of exploits that can do some serious damage.

Listed below are three of the most serious problems that, if ignored, can cause some serious security problems with your email systems.

1. Malware being spread via email

To say that spam levels are dropping dramatically is almost a half truth. While users are seeing less spam advertising pharmaceuticals, financial services, pornography and work at home schemes it doesn’t necessarily mean that spam itself is being beat back.

Actually, while the use of spam for advertising and marketing may be down the numbers are increasing for spam messages that carry something far worse than the Nigerian prince scam. These messages actually contain malware or links to malicious sites.

Knowing full well that many users have been taught not to download attachments they don’t trust, cyber criminals have turned to simply inserting a link to a web site in their emails. When the victim clicks the link, they are taken to a site that runs scripts to infect their computers with Trojan horses, keystroke loggers and other types of malicious software.

2. Information leaks

Not all threats come from outside. Anyone who has worked to secure confidential data knows all too well that one of the biggest areas of concern is information being leaked from an inside threat.

Inside threats happen through a variety of means. You could have a disgruntled employee who is looking to hurt the company or you could have an employee who is looking to make a little extra money moonlighting as a corporate spy. There have even been instances where someone lands a job with a company for the sole reason of stealing confidential or proprietary information.

While these scenarios seem like they came from a Hollywood studio, they do happen – just not that often.

Most likely, you will find that information is leaked by accident. An employee includes something in an email message that is considered sensitive. That email, once it leaves the protection of your company, can now be forwarded on or even intercepted in transit. The contents can then be easily exposed revealing trade secrets, private information or even embarrassing content.

3. Go phish

Phishing is a threat that has been on the radar of most IT administrators for some time. And with recent data breaches, like the recent attack against Epsilon, millions of corporate email addresses have been compromised and are ready to be used in phishing attacks.

The scary part of phishing attacks nowadays is that it is becoming harder to tell them apart from legitimate emails. Take a look at recent PayPal and banking emails that have been sent out requesting people to reset their account passwords or log in to address some issues with their account.

It is becoming tough for people to tell the difference between a real request from their financial institution and one aimed at compromising their login details.

Of course, financial data isn’t the only thing that phishers chum the waters for. They know full well that a majority of people use the same user name and passwords for a majority of web sites. If they can capture a password, they can usually recreate the username for your businesses network resources to allow them free reign over anything the victim has access to.
Safeguarding against email based attacks is something that every IT admin needs to take seriously if they want to protect their network. Employing a solution that addresses the mail servers, mail client, users and other network resources is one of the key steps to protect against as many points of attack as possible.

Addressing Three Major Email Threats

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

The Exchange Team first indicated it was coming back in July 2011. We’ve been anxiously awaiting it ever since, and it has finally arrived. Microsoft’s free PST Capture Tool is available for download now.

This tool is designed to hunt down PSTs on your network and provide administrators with a management console which will enable them to either migrate the content to Exchange 2010 on premise, or to Office 365. It uses a client-server approach, requiring a management console to be installed on a server, and agents to be deployed to all systems which you want to scan for PSTs.

To use the tool you must first install the PST Capture Console onto a workstation or server with Outlook 2010 (64 bit) installed. During the install you specify the service account to use, and the port the service will bind to if you don’t want to use the default 6674. Then you install the PST Capture Agent on each computer that you want to search for PSTs. During the install of the agent you specify the FQDN of the Capture Console, and the port if you changed it from the default.

You’ll also need a service account that has been assigned  permissions based on the import scenario you want to implement.

Running import operations can be bandwidth intensive. The agent will copy the PST files to the server running the management console. Then the management console server will either copy the data to a CAS server which will then copy it to a mailbox server, or if the destination is in Office 365, the management console will copy the data directly to Office 365. If you were keeping count, that means a PST might transit the network anywhere from two to four times, depending upon the source of the PST (local hard drive or network share) and the destination. It’s recommended that the management console server be local to the CAS server as well, and in the case of Office 365 customers, close to the Internet egress point.

With the release of the PST Capture Tool, admins now have a free tool to help finally eradicate PST files. Good hunting!

Rejoice, for the PST Capture Tool Has Been Launched!

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Administrators confident about the safety of their data encrypted on company laptops should start squirming if a recent court decision passes muster in the United States.

The case involves a Colorado woman who has been ordered to open the encrypted drives on her laptop for federal investigators.

Unlike the cops on television shows and movies, who always seem to have a computer wizard on hand to decrypt a hard drive or crack a password, law enforcement authorities in Colorado, stymied by the encryption on a notebook in the possession of Romona Fricosu, simply went to a judge and asked him to order her to type in her password so they could see what was in the encrypted files.

In arguing against opening the files, Fricosu claimed doing so would violate her civil rights, in particular her Fifth Amendment rights against self-incrimination. Her reasoning was that the government, by forcing her to give up her password for decrypting the drive, were forcing her to incriminate herself if there were anything on the drive tying her to their criminal investigation of a mortgage scam. They believe Friscou is involved the scam that defrauded banks in the Colorado Springs area of some $900,000.

Federal District Court Judge Robert Blackburn didn’t buy that argument. Fricosu might be self-incriminating  herself if she were being asked to utter the password to the files or to give it to the investigators in some other way. However, she was only being asked to type in the password.

The government said it wasn’t interested in knowing what the password was. In fact, it said Fricosu could type the password into the laptop without any government operatives hovering over her. For that reason, the password could be treated like a key is treated in the physical world. Since the courts have ruled that the government can compel someone to give it the key to a safe or other repository of potential evidence in a case, Judge Robinson reasoned, it can compel Fricosu to type in her password.

Although the Fricosu case will be appealed and isn’t settled in law yet, it should give administrators some food for thought. It’s not that far of a stretch, for instance, from treating a password for decrypting files  as a key to treating passwords to anything that way.

That can have broad implications for your data’s security should you ever have to lock horn with any government for any reason. While Fricosu was involved in a criminal matter, the logic underlying the case could be extended to non-criminal government activity such as tax audits or compliance reviews.

With that in mind, should alternatives to passwords be considered? For example, if voice recognition were used to replace passwords, then the “utterance” test might be met and your data might be better protected against intrusive legal searches. Then there’s the question of whether other biometric solutions used for authentication are as legally vulnerable as simple passwords. If a retina has to be supplied to open a laptop, is that a potential act of incrimination?

One thing administrators should take away from the Fricosu decision, should it be upheld by the appellate courts, is that their passwords and the passwords of their organization’s users aren’t as safe as they as they used to be—and neither is anything that can be decrypted with a password.

Government Can Force You to Decrypt Your Data

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Back in early December, I wrote an article called A Deeper Look into Exchange 2010 SP2 where I discussed some of the new changes being added to Exchange and to the Active Directory schema. If you didn’t read that article, click the link above, and then come back here. It’s okay, I’ll wait. Back and ready to go? Good. In that article I indicated that the new extension attributes could be available for customers who want to store additional information in Active Directory but don’t have suitable attributes already in place, and don’t want to roll their own schema extensions.

In a new post over at the Exchange Team Blog, You Had Me at EHLO, Nino Bilic wrote an article a couple of weeks ago that has prompted me to update you about this, and to revise what I said, in his post on Custom (aka. Extension) attributes in Exchange 2010 SP2 and their use, Bilic talks in detail on the two additions to the object class ms-Exch-Custom-Attributes.

Here’s where clarifications are necessary, and where I had the wrong idea about all those new extension attributes. Microsoft considers ms-Exch-Extension-Attribute1 through 15 to be “all yours”. As Bilic stated it, “you are free to use them as you used them before”. If you ever read the TechNet article Understanding Custom Attributes, then you probably are already using those first 15 attributes for anything and everything you might want to store in Active Directory. The Exchange Management Shell even makes it trivially easy to set/edit/remove values from those attributes, shorthanding them to “CustomAttribute#” and allowing you to write to them using the Set-Mailbox command. Logic suggests that by creating CustomAttribute16 through 45, Microsoft was just being generous and giving you more fields to play with. Not so much.

According to Bilic, CustomAttribute16 through 45 are for “future use” and should be considered reserved. What they are being used for remains to be seen, and there are no hints in the article or elsewhere, but CustomAttribute16 through 45 cannot be modified using the Set-Mailbox –CustomAttributeX command the way 1 through 15 can be, nor are they exposed in the UI, and Bilic went on to say “we cannot recommend that you use non-Exchange tools to edit their values because we might use those attributes in the future for various Exchange features.” Can you update those values with ADSI Edit or some third party tool? Probably. Should you? Not a chance.

The bottom line is to keep your hands off of CustomAttributes 15 through 45, but to also keep your fingers crossed that some new functionality will be forthcoming. If the 15 attributes we’ve had all this time are not enough, keep in mind that SP2 did add ms-exch-extension-custom-attribute1 to 5, which are multi-value attributes that can store tons more information about an object. They have been shorthanded to ExtensionCustomAttribute1 to 5, and can be accessed using the Set-Mailbox command. Hopefully that will be enough to fit any needs you have in the foreseeable future.

30 New Custom Attributes? Not So Fast

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Email is one of the most important communications tools for businesses. When it stops working, people start to get nervous.

While there are many things that a user can do to mess up their email, many of these problems can be resolved with a restart of the software or the computer.

However when the old standby of restarting doesn’t work, it is time for the email administrator to start looking into the issue a bit more deeply.

Here are some of the more common errors found in Outlook 2007 along with some of the ways you can make things right again:

1. Error message that reads: “Cannot open your default e-mail folders. The information store could not be opened.”

This issue can be fixed by first locating Outlook.exe that can be found here: C:\Program Files\Microsoft Office\Office12.

Next, right click Outlook.exe and then click on Properties.

On the Compatibility tab, clear the check box that reads ‘Run this program in compatibility mode’. Then click Ok and restart Outlook.

2. Error message that reads: “Your Microsoft Exchange Server is unavailable.”

This error is a bit trickier to resolve only because there can be many different causes.

No data connection – test your SMTP connection using telnet. If you are unsure how to do this, Microsoft has provided a guide on their TechNet site that walks you through this process: http://technet.microsoft.com/en-us/library/bb123686.aspx.

Office Outlook files are locked – there are times when .ost and .pst files are accidentally, or purposefully, set to read only. Check the permissions of these two files by navigating to:

C:\Users\<username>\AppData\Local\Microsoft\Outlook\ for .pst files and C:\Program Files\Microsoft Office\Office12\ for .ost files. Make sure that neither is set to read only.

Third party applications are interfering with Outlook – many programs, including anti-malware solutions, can interfere with Outlook connecting to the Exchange Server. To check to see if this is the cause, start Outlook in safe mode.

Outlook files are corrupted – this can happen after an upgrade is applied to Outlook. If any of the .dat files listed below are present they should be deleted or renamed.

• Extend.dat – Located in C:\Documents and Settings\<username>\Local Settings\Application Data\Microsoft\Outlook\
• Frmcache.dat – Located in C:\Documents and Settings\<username>\Application Data\Microsoft\Forms\
• Views.dat – Located in C:\Documents and Settings\<username>\Application Data\Microsoft\Outlook\
• Outcmd.dat – Located in C:\Documents and Settings\<username>\Application Data\Microsoft\Outlook\

All the files, with the exception of Outcmd.dat will be re-created. The Outcmd.dat file saves customized toolbar settings so if it is removed these settings will have to be re-applied.

3. Office Outlook will not open personal folders or personal folders do not show up in Outlook.

Personal folders are often the root of many problems related to Outlook. Microsoft has published the Inbox Repair tool, Scanpst.exe, that can be used to scan .pst and .ost files for errors in the file structure. If this is not intact, it will reset the file structure and rebuild the headers.

This tool will only work on the files that reside on your computer’s hard drive, not the files on the Microsoft Exchange Server.

This will also help to resolve the error message: “Cannot open your default e-mail folder. The file c:\users\owner\documents\software info\outlook.pst is not a personal folders file”.

4. Error messages that read either: “The action cannot be completed. The connection to the Microsoft Exchange Server is unavailable. Your network adapter does not have a default gateway” or “Your Microsoft Exchange Server is unavailable”.

This error occurs when Outlook is unsure of the default gateway address. The former is the error message that shows when the Outlook profile is configured automatically and the latter appears when the profile is manually configured. Both have the same fix.

To repair this you will need to edit the registry so clicking on Start and then Run is necessary. Then, enter regedit in the Open box and click OK.

Next, navigate to the registry key: HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\RPC. On the Edit menu, point to New, and then click DWORD Value.  Type DefConnectOpts, and then press ENTER. Now, right-click DefConnectOpts, and then click Modify. In the Value data box, type 0, and then click OK.

5. None of the authentication methods supported by this client are supported by your server.

This happens to people when they use their computer in multiple locations. For example, a laptop is taken home and connected to the home network or perhaps a computer is taken on the road. Basically, it comes from authentication rules for the SMTP server.

When this error occurs go to the Account Settings tab and click on Change then More Settings. Now select the Outgoing Server tab.

The option that reads: “My outgoing server requires authentication” and the one that reads: “Log on to incoming mail server before sending mail” should both be looked at. If there is a check in the option box remove it.

5 Common Outlook Errors and How to Fix Them

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Often, Exchange administrators will receive escalated help desk tickets from users complaining that Exchange is “slow” and demanding resolution. These sorts of tickets (slow being at best a relative term and never specific enough about what precisely is considered to be slow) can be extremely challenging to work, since the subjective nature of slowness is often combined with an inability to replicate the problem, or the problem is intermittent. The Exchange admin can take a look at the server(s) for high CPU utilization, low memory conditions, disk and network queue lengths exceeding the norm, and finding nothing, shrug it back off to the desktop support team as a client issue. While it is often a client issue, there are several places between Outlook and a user’s mailbox that can cause intermittent slowness, and are fair to call networking bottlenecks. In a six part series of articles, we’ll look at how Exchange interacts on the network with various other services to help you identify network issues, and troubleshoot them when they occur.

In many cases, troubleshooting Exchange network bottlenecks will require a network trace, and may also require performance monitor counters. This series of articles will talk about both of those in general terms; how to use NetMon or Wireshark, and PerfMon are out of scope. In Part 3 of this series, we’re going to discuss the connectivity you need to permit through firewalls for Exchange to function properly on the network.

Firewalls

There are at least three places where a firewall can cause problems for Exchange. The most common is at your Internet border, when you are trying to support a protocol and the firewall is not permitting the necessary traffic. The second is between your DMZ and the internal network, which can cause issues for both Edge Transport servers and Client Access Servers, depending upon whether you pass traffic into them directly (which is not recommended) or you publish the CAS services using TMG or some other reverse web proxy. The third, which is both the least common and the most problematic, is when there are firewalls between different internal Exchange servers, or between Exchange servers and Active Directory.

Clients on the Internet must connect to the CAS servers for the various protocols they will use. Other Internet mail servers must connect to the Edge Transport server to exchange SMTP messages, and all Exchange server roles except the Edge Transport Server must query AD directly for configuration information, and to perform LDAP lookups for servers in different sites. They will also need to communicate with Active Directory to authenticate users. Edge Transport servers have to communicate with Hub Transport servers both to update their configuration, and to pass SMTP traffic in to the internal network. Any time a firewall is between two Exchange servers, or between an internal Exchange server and either Active Directory or any other part of the Exchange environment, you must ensure that all required traffic is permitted to pass through the firewall. Firewalls frequently translate IP addresses, called NAT. NAT is okay for some protocols; for others not so much. Windows 2008 and 2008 R2 servers will source all ephemeral connections from ports between 49152 and 65535. If you have any Exchange servers running 2003 or 2003 R2, you will need to expand that range to 1025-65535. The same can be said for clients. Windows Vista and 7 will source their connections from ports between 49152 and 65535. XP clients will source from 1025 to 65535.

Let’s look at each of the roles to see more about the required connectivity.

Edge Transport Server Role

Of course, your firewall needs to permit inbound TCP 25 from the Internet (ip any) to enable other Internet mail servers to send it email, and source ports can be anything from 1025 on up. You should also permit TCP port 587, which is commonly used by clients sending TCP over TLS connections. Older firewalls sometimes attempt to perform a rudimentary form of Intrusion Protection (fixup, inspect, etc.) which can often cause more problems than it solves, so consider carefully whether to enable that or not.

The Edge Transport server doesn’t access Active Directory directly, it stores it configuration in an instance of Active Directory Lightweight Directory Services. It uses an Edge Subscription to subscribe to a Hub Transport server in an Active Directory site, which will use the Microsoft Exchange EdgeSync service to synchronize Active Directory data to AD LDS. The Edge Transport server must be able to communicate to each and every Hub Transport server within the site it is subscribed to over TCP port 50636. That’s every Hub Transport server in the site, not just one or two, and it will source its queries from an ephemeral port between 49152 and 65535. If you add a Hub Transport server to the site, you must update your firewall rules to include the new server and update your Edge subscription.

You can use NAT for both Internet traffic in to the Edge Transport server, and from the Edge Transport server into the Hub Transport servers in the subscribed site.

Hub Transport Server Role

The Hub Transport server must contact Active Directory to perform message categorization, necessary for recipient lookup and routing resolution. This will include the location of the recipient’s mailbox and any restrictions or permissions that may apply. It will also use LDAP queries to expand the membership of distribution lists to determine membership of a dynamic distribution list.

It’s best if there is no firewall between a Hub Transport server and the Domain Controllers in the same site, but if you must place a firewall between them, ensure that the Exchange server can reach all Domain Controllers in the site over all the following ports and protocols.Collapse this tableExpand this table

Collapse this tableExpand this table

NAT is no good here; it can break RPC DCOM traffic which is used for some Active Directory functions.

Client Access Server Role

The Client Access server role services clients connecting from the Internet who want to use Outlook Web App, POP3, IMAP4, or ActiveSync. When a connection is received, the Client Access server authenticates the user against AD and then queries to determine the appropriate mailbox server. If the user’s mailbox is in the same site, the user is connected directly to their mailbox. If in a different site, the connection is redirected to a Client Access server in the remote site.

If you are going to provide client connections directly to the CAS server, you must permit the following for the relevant client protocols.Collapse this tableExpand this table

Unified Messaging Server Role

The Unified Messaging server will need essentially the same connectivity as the Hub Transport server role, plus whatever required ports are necessary for your particular VoIP gateway. Consult your vendor’s documentation for those specifics.

Mailbox Server Role

The Mailbox server will also need the same connectivity as detailed for the Hub Transport server role.

Limiting RPC ports

Firewall admins don’t like to carve large holes in their walls, and will often request that you limit the port ranges used by RPC connections. This is supported, and well documented, but be warned. It is very common to limit RPC connections to too narrow a range of ports. This will manifest as random failures particularly at peak load times, with tons of 1722 errors. If you must restrict RPC ports, I suggest you start with a range of at least 1000 ports, and carefully monitor clients and servers to ensure that this is enough to support all connections during peak times.

Troubleshooting Exchange firewall issues

Knowing the ports Exchange uses will help you troubleshoot issues. If you suspect Exchange is having a problem caused by a firewall, it’s best if you can work directly with the firewall administrator, who can monitor the source and/or destination IP addresses to see if rules are blocking. If that is not possible, you can test connectivity between Exchange and Active Directory or other Exchange servers by using the PortQueryUI tool. You can also use PING, the TCPING tool, or even the Windows Telnet client to see whether you can connect to the port or not.

PortQueryUI can provide specific success or failures, but you can use PING to make sure you can reach the destination server, and then TCPING or Telnet to confirm whether or not you can make a connection on the specific ports required. If you get timeouts or refusals, and you have confirmed the destination server is up and running, then you are probably dealing with a firewall issue. There’s no real workaround here; the firewall admin must permit the required traffic for all services.

Coming up next

In Part 4, we will look at the issues that can cause Exchange problems when NICs are involved, and how to troubleshoot those problems. Here’s a rundown of the six parts in this series. We’ll update with live links as each part is published over the next several weeks:

1. Introduction and DNS
2. Active Directory
3. Firewalls (this post)
4. NICs
5. RPCs
6. Client side issues

Troubleshooting Exchange Networking: Firewalls (Part 3)

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Google recently hung a ‘going out of business’ sign on its Message Continuity service for users of Microsoft Exchange. Google will continue to provide the service to its users until their contracts run out, but after that, they’re on their own.

Since the service was launched a little over a year ago, “hundreds” of businesses have subscribed to the offering, which uses Google’s cloud to provide email continuity when a Microsoft Exchange environment is interrupted for any reason.

Hundreds of users, though, can’t compete with the “millions” of businesses that have moved their entire email operation to Google Apps, so Searchzilla has decided to scrap its continuity product for Exchange  and concentrate all its resources on its application suite.

Current users of the continuity product were “encouraged to consider using Google Apps as their primary messaging and collaboration platform” in a company blog written by Vice President of Product Management Dave Girouard.

The brusque departure by Google from the Exchange disaster recovery scene contrasts sharply with how it entered it:

“Google Message Continuity advances our commitment to providing rapidly deployed, cost-effective email management solutions for organizations of all sizes,” Enterprise Product Manager Matthew O’Connor wrote when the continuity product was announced.

Looking back on the announcement, it appears that Google’s “commitment” to the Exchange market was as solid as an adolescent’s commitment to the latest fad.

That’s not to say that Google’s intentions in offering an Exchange product weren’t clear from the start for careful readers of the company’s pronouncements. “Additionally, for organizations interested in eventually moving to Google Apps, Google Message Continuity can provide a smooth bridge to the cloud,” O’Connor slyly observed in his blog item.

O’Connor’s colleague, Rajen Sheth, the group product manager for Google Apps had a similar pitch at the time:

“Google Message Continuity can also help organizations transition to Google Apps down the road,” he wrote. “Since Microsoft Exchange and Gmail are always in sync with one another, there’s no need to migrate email data when eventually deploying Google Apps.”

Little did those who signed on for Google’s continuity solution realize when they did so that if they didn’t “transition” to Google Apps fast enough to suit the Ferret King, they’d be left looking for another business interruption solution within a year’s time.

Google has been criticized in the past for its flighty attitude toward product development. Some detractors maintain that Google often enters markets to be disruptive, not competitive. Like a sea gull boss, it will undercut competitors in a market and when things don’t work, abandon that market, leaving customers who had faith in the Google brand to clean up the mess.

That kind of product management may work with consumers, but it leaves something to be desired in the business world. Google’s competitor in the enterprise market, Microsoft, knows that. While the Redmond crew have suffered a few slings and arrows for sticking with products too long, their commitment to legacy products has been an important, if sometimes overlooked, part of their success in the business market.

Google’s forsaking of Message Continuity brings to mind some remarks by Microsoft Senior Director of Online Services Tom Rizzo in his famous “Google Graveyard Spooks Customers” blog written on Halloween last year:

“Google releases experimental products and tracks adoption to determine whether to continue providing them,” he wrote. “Its products are like spaghetti, Google throws them up against the wall to see if they stick.”

“The burials of de-supported products are more examples of what is convenient for Google and not good for business,” he added.

Google Deserts Exchange Users by Killing Message Continuity

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

If you are still on an Exchange 2003 or 2007 platform and are starting to plan your upgrade to Exchange 2010 (or your to the cloud), you are probably looking at your public folders and thinking to yourself: “oh gods no please don’t make me go through them! I promise I will be good from now on and eat my vegetables and clean my room please oh please oh please don’t make me deal with the public folders and please don’t send me to the cornfield!”. Okay, you might not have quite that, emotional reaction, but if you aren’t dreading the task, you haven’t started to think about it yet.

1. Eventually, they won’t be supported anymore.

2. Anybody remember where we stored that customer list?

3. Collaboration? Not so much.

4. Backups? We don’t need no stinking backups!

5. Public Folder management tools, what Public Folder management tools?

6. Wow! I remember that. Gosh, I haven’t seen that in years!

7. When I grow up, I want to be SharePoint.

7 Reasons Public Folders Need to Go Away

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Gates: Momentous security memo

For computer security experts, January 15 marked the anniversary of a red letter day. It was the 10th anniversary of the day that Microsoft decided to get serious about security.

On that day in 2002, a memo from Bill Gates to Microsoft employees declared the company would be entering a new era, an era of “Trustworthy Computing.”

“In the past,” Gates wrote, “we’ve made our software and services more compelling for users by adding new features and functionality, and by making our platform richly extensible. We’ve done a terrific job at that, but all those great features won’t matter unless customers trust our software.”

“So now,” he continued, “when we face a choice between adding features and resolving security issues, we need to choose security.”

Gates’ commitment to security came when the Windows world was reeling from two monster malware attacks from the previous year Code Red and Nimda. Code Red exploited buffer overflows to attack Internet Information Services (ISS) running under Windows Server. It infected an estimated 300,000 PCs.

Unlike Code Red, Nimda was a worm that used multiple attack vectors to rapidly infect computers connected to the Internet. The technique was extremely effective and within 22 minutes of its release on September 18, 2012, it became the most widespread malware in the world.

It’s with that backdrop that Gates emailed his memo to his employees. One group of workers was particularly glad to see their boss’s missive: the company’s malware fighters.

“It’s not an understatement that the memo felt, to me, like the arrival of Gandalf and Eomer at Helm’s Deep in the film The Lord of the Rings: The Two Towers at a moment of great despair; at last we were getting some relief and might survive” Christopher Budd, who worked on security issues for 10 years at Microsoft, wrote in Betanews.

“In a single movement, Gates enshrined security, privacy and reliability as central, aspirational ideals,” Budd observed. “Like all ideals, there have been better and worse times in realizing them, but their central importance was never open to question. That memo eliminated the resistance that made our work so hard and gave us the power to do the right thing for customers.”

Budd asserted that the memo gave the security and privacy factions in the company the power to stand toe-to-toe with those primarily concerned with revenue and growth. He wrote:

“In a way, it represents a statement of conscience for the company and we used it as such, with success.”

Since the memo was issued, Microsoft has made security an important part of its product development cycle. That’s led to security features like library randomization and BitLocker drive encryption in Windows 7 and Secure Boot, a way in Windows 8 to foil BIOS attacks. It has made Windows Server IIS as secure as its open source competitor, Apache, too.

It has also lifted Microsoft’s browser, Internet Explorer, from a security nightmare to one of the most secure ways to surf the Web today. A 2010 report from independent software tester NSS Labs found:

“Internet Explorer 9 was by far the best at protecting users against socially-engineered malware.”

Unfortunately, it’s hard to change a bad security reputation forged over many years and IE’s user share has fallen from its once dominant position of more than 90 percent to under 50 percent of all users.

Microsoft’s Trustworthy Computing Program Turns 10

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Customize the Exchange Management Shell as an Exchange administrator, it’s only a matter of time before you embrace the dark side and come to know the true power of shell. The Exchange Management Shell is the direct interface between you and the underlying PowerShell cmdlets that are used to query, configure, and manage Exchange. Getting comfortable with a command line interface after years of GUI work is a big shift for many admins, but if you start out slow, and work your way through things step by step, you’ll soon find that you are a PowerShell Jedi. Making something your own is the first step towards getting comfortable with it, so in this post, we’ll see how to customize the Exchange Management Shell to make it your own.

Again, the Exchange Management Shell (EMS) is simply Exchange’s pathway into PowerShell. If you look at the properties of the EMS shortcut, you will see that it does three things:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command “. ‘C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1′; Connect-ExchangeServer -auto;”

1. It launches PowerShell,
2. It runs a PowerShell script called RemoteExchange.ps1, and finally
3. Automatically connects to the localhost Exchange server.

PowerShell uses profiles to control how it looks and feels. You can also use profiles to configure PowerShell with your own aliases, functions, etc. If you examine the RemoteExchange.ps1 script referenced in the path above, you will find that it configures the size of the EMS window, provides the tips you see at launch, and defines some functions specific to Exchange.

To tailor the appearance of your EMS, you can create/edit your PowerShell profile. You won’t always have a profile to start with. When you open the EMS, type this command:

Test-Path $profile

If you have a profile the result will show True. If you don’t, it will show… care to guess? That’s right, False. To start working with your profile, enter this command:

notepad $profile

If you didn’t have a profile, you will be prompted to create one. Now that you have a profile, what can you do? I like to have the EMS automatically open in the scratch directory I tend to save working scripts, output files, etc., in and change up the colors a little bit. Here’s an example profile file:

$Shell = $Host.UI.RawUI
$Shell.WindowTitle="A little knowledge is a dangerous thing"
$Shell.BackgroundColor="Black"
$Shell.ForegroundColor="Green"
Set-Location C:\\scratch

Let’s see what we’re doing here. First, we create a variable called $Shell, and populate it with the properties of the $Host.UI.RawUI, which stores all the attributes of the UI. Then, we set the value of the WindowTitle attribute (quote enclosed), set the foreground and background color, and then essentially we CD into our c:\scratch directory. Here’s a list of the colors you can use:

• Black
• Blue
• Cyan
• DarkBlue
• DarkCyan
• DarkGray
• DarkGreen
• DarkMagenta
• DarkRed
• DarkYellow
• Gray
• Green
• Magenta
• Red
• White
• Yellow

Save the file, and then launch the EMS. You should see your EMS with the foreground and background colors that you chose, and that your current directory is c:\scratch (or whatever you chose). Notice what you don’t see? Your Window title should display “Machine:FQDN” of your Exchange server. When you use the Connect-Exchange server command, it updates the window title to reflect the server. However, when you launch the regular PowerShell (instead of the EMS) you will see your catch window title at the top.

We’ll look more into PowerShell and the power of the EMS in upcoming posts. If you have a particular customization you like to use, please feel free to share it in a comment below.

Customize the Exchange Management Shell

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In an age where millions of emails are sent every day it is hard to find someone who hasn’t made a mistake when sending a message.

If you are using Microsoft Outlook and Exchange, you can quickly recall a message and delete unread copies, if you are lucky that is and no one has opened the email. If someone has already opened your errant message, then it’s too late.

Companies have become a bit more cognizant that some employees are just a bit too quick to pull the Send trigger on their mail. To compensate, many have put into place a time delay that gives someone the opportunity to think twice about a message that was sent out and stop it before it is delivered.

Just recently, the New York Times suffered a rather embarrassing incident where they had planned to send a few hundred emails out to some of their subscribers offering them a discounted rate if they did not cancel their subscription. Instead the message went out to over 8 million people.

That was mistake number one.

This was then followed up by a message that read:

“If you received an email today about canceling your NYT subscription, ignore it. It’s not from us”

sent out via Twitter. So they were blaming the mistake on someone else, a spammer perhaps.

But, as it was later discovered, the Times was the guilty party. They did send the initial message and then pawned off the responsibility.

Where the mistake hurt

This gaffe wound up costing the Times. Not only was their reputation hurt, but so was their bank account.

Since a discounted rate was promised to the few hundred who were thinking of cancelling their subscription to the Times, other customers felt slighted. Their loyalty, so it seemed, accounted for little reward.

To make up for it, the Times extended the discount to everyone who received the errant email, but only for part of a day. By the afternoon of their offer, they had put a halt to the discounted rates. This decision then led to a Twitter account called @NYTSpam that made fun of the error fully disclosing that it was a:

“Parody account. Not affiliated with @NYTimes or actual spammers — just sick of bad digital strategy.”

The account currently has over 200 followers.

The Times is not alone when it comes to paying the price for a bad email going public. These things actually happen all the time. But when it happens to a small business, we don’t really hear about it.

To keep the lid on scandals and humiliation that can be suffered due to email, it is important that you cover certain things with your employees.

Anyone who emails on behalf of the company should understand the following:

1. Never send an email when you are angry or emotional. This leads to things being said that you may want to take back.
2. Write, edit, send. Never type out an email and hit the send button without reading it over. Not only for spelling and grammar errors that could hurt your reputation, but also for the tone of the email. People read into things and if the tone is not what you intend it could lead to problems later.
3. Check your list. This ties in directly to the Times situation. Make sure that you are sending your email message to the right people. This becomes more important with so many organizations automatically populating the TO and CC fields as you type names. Make sure that you don’t rely simply on the names suggested to you. Be careful using the Reply to All as well.
4. Never punish or praise in an email message. Not only can the content of an email be misconstrued because of a lack of emotion, but it can also become evidence or public record. If you fail to follow human resources procedures, email can be a pretty solid form of documentation.
5. Don’t share company secrets via email. Whether they be financial, trade or even personal secrets they should never be relayed through an email message. It is far too easy for someone to accidentally, or purposefully, forward that message on to others.

Common Mistakes When Sending Emails

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Often Exchange administrators will receive escalated help desk tickets from users complaining that Exchange is “slow” and demanding resolution. These sorts of tickets (slow being at best a relative term, and never specific enough about what precisely is considered to be slow) can be extremely challenging to work, since the subjective nature of slowness is often combined with an inability to replicate the problem, or the problem is intermittent. The Exchange admin can take a look at the server(s) for high CPU utilization, low memory conditions, disk and network queue lengths exceeding the norm, and finding nothing, shrug it back off to the desktop support team as a client issue. While it is often a client issue, there are several places between Outlook and a user’s mailbox that can cause intermittent slowness, and are fair to call networking bottlenecks. In a six-part series of articles, we’ll look at how Exchange interacts on the network with various other services to help you identify network issues, and troubleshoot them when they occur.

In many cases, troubleshooting Exchange network bottlenecks will require a network trace, and may also require performance monitor counters. This series of articles will talk about both of those in general terms; how to use NetMon or Wireshark, and PerfMon are out of scope. In Part 2 of this series, we’re going to discuss how Exchange is dependent upon and interacts with Active Directory on the network.

Active Directory

There’s a ton of network interactions between Exchange servers and Active Directory, which is why you are required to have a Global Catalog server in every site in which you have an Exchange server. An Active Directory site is usually defined as a collection of subnets with sufficient bandwidth to support replication, and that can lead to sites spanning WAN links. While the WAN may have sufficient bandwidth and low enough latency to support Active Directory replication and authentication traffic, any AD client that is in a site may connect to, and query, and Domain Controller within that site. When the target of queries is across the WAN, the total latency of the WAN link can add up to noticeable delays. Understanding just how much goes on between your Exchange server and your Global Catalog server may be enough to make you change the word “site” to “subnet.” Exchange servers will bind to a randomly selected domain controller and global catalog server in the same site, to minimize WAN traffic. Ensure that there are redundant servers will keep WAN traffic to a minimum, and optimize Exchange performance.

Note: Read-Only domain controllers are not usable by Exchange. Exchange must access writable domain controllers.

Configuration information

The configuration partition in Active Directory contains critical data about the forest-wide configuration. Exchange configuration information can be found in a subfolder of the Services container in the Configuration partition. This includes:

1. Address lists
2. Address and display templates
3. Administrative groups
4. Client access settings
5. Connections
6. Messaging records management, mobile, and UM mailbox policies
7. Global settings
8. E-mail address policies
9. System policies
10. Transport settings

All Exchange server roles, except the Edge Transport Server, will query AD directly for this information. Here’s more specific information on how each role depends upon AD. You can also read more about that here http://technet.microsoft.com/en-us/library/aa998561.aspx.

Hub Transport Server Role

The Hub Transport server must contact Active Directory to perform message categorization, necessary for recipient lookup and routing resolution. This will include the location of the recipient’s mailbox and any restrictions or permissions that may apply. It will also use LDAP queries to expand the membership of distribution lists to determine membership of a dynamic distribution list.

The Hub Transport Server will use cached information regarding the AD site topology to determine routing for message delivery between sites. If the Hub Transport server determines that a mailbox is in the same site, it will deliver the message directly to the Mailbox server, otherwise it will route the message to a Hub Transport server in the destination site.

The Hub Transport server uses the application partition of Active Directory to store and access configuration information, including transport rules, journal rules, and connectors.

Client Access Server Role

The Client Access server role services clients connecting from the Internet who want to use Outlook Web App, POP3, IMAP4, or ActiveSync. When a connection is received, the Client Access server authenticates the user against AD and then queries to determine the appropriate mailbox server. If the user’s mailbox is in the same site, the user is connected directly to their mailbox. If in a different site, the connection is redirected to a Client Access server in the remote site.

Unified Messaging Server Role

The Unified Messaging server queries Active Directory to retrieve global configuration information, such as dial plans, IP gateways, and hunt groups. When a message is received by the Unified Messaging server, it matches the telephone number to a recipient address, then the location of the user’s mailbox. It can then route the voicemail message to a Hub Transport server for delivery to the mailbox.

Mailbox Server Role

The Mailbox server also stores configuration information Active Directory, including agent configuration, address lists, and policies. The Mailbox server will use this to enforce mailbox policies and global settings.

Edge Transport Server Role

The Edge Transport server doesn’t access Active Directory. It stores it configuration in an instance of Active Directory Lightweight Directory Services. It uses an Edge Subscription to subscribe to a Hub Transport server in an Active Directory site, which will use the Microsoft Exchange EdgeSync service to synchronize Active Directory data to AD LDS.

Site definitions

There are two rules of thumb for Active Directory site design and how it impacts Exchange:

1. Make sure every single subnet that hosts an Exchange server belongs to a site
2. Don’t let any of those sites span the WAN, no matter how much bandwidth you have available.

If an Exchange server cannot determine its AD site because the subnet does not belong to a site, the MSExchangeDSA will fail with a 2114 and MSExchangeSA will fail with a 1005. In both cases it is because Exchange could not determine the AD site based on the subnet. Even the fastest WAN links have higher latency than the slowest LAN links, and that latency will have a cumulative and negative impact on Exchange performance as the server is waiting on responses from domain controllers if the DC is on the far side of the WAN from the Exchange server.

Troubleshooting Exchange interaction with Active Directory

Knowing how Exchange depends upon Active Directory will help you troubleshoot issues. The four main categories of problem are:

1. Network latency between the Exchange server and GC/DC
2. Firewall rules blocking connection attempts
3. Incorrect site configuration
4. Replication problems within AD

If you suspect Exchange is having a problem accessing Active Directory, first ensure that Exchange can communicate with a domain controller for each domain in the forest that has users with mailboxes, and that there is at least one domain controllers in the same site that is a global catalog server. Look for errors including 2114, 1005, and 1722.

Test connectivity between Exchange and Active Directory by using the PortQueryUI tool, and the response times to LDAP queries using LDP.EXE and a protocol analyzer. And of course, ensure that you have no replication problems with your Active Directory. A domain controller that stops replicating because of DNS islanding or other connectivity issues with the rest of the forest will directly impact AD. Changes in AD (like name, group membership, SMTP proxy addresses, etc.) must replicate to all domain controllers that Exchange relies upon before you can be sure that Exchange will pick up on/display the differences.

Performance will be enhanced by redundancy. When possible, ensure that there are multiple global catalog servers in the same site as every Exchange server, and that every domain in the forest with Exchange users is represented.

Performance of Exchange will also improve directly with the capabilities of those domain controllers. When the DC is able to cache the entire Active Directory in memory, response to queries from Exchange will be much faster. Look at implementing 64bit DCs with enough RAM to cache the entire database.

On a domain controller a quick way to check for replication problems is to run this command in an administrative command prompt

Repadmin /replsummary [enter]

Check for fails, servers that are down or unreachable, and larger times since the last replication event.

Coming up next

In Part 3, we will look at the connectivity requirements for Exchange as they relate to firewalls, and how to troubleshoot those problems. Here’s a rundown of the six parts in this series. We’ll update with live links as each part is published over the next several weeks:

1. Introduction and DNS
2. Active Directory
3. Firewalls
4. NICs
5. RPCs
6. Client side issues

Troubleshooting Exchange Networking: Active Directory (Part 2)

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

I want you all to go grab your favourite marketing person and make them read this post. You know the ones I am talking about. The one that doesn’t understand why they have to take the 3600dpi 8GB PDF that could be blown up to the size of the Empire State Building without looking grainy, and reduce it for sending over email to a customer. The one who came in early last week to send an email blast to a 1000 person customer list that they bought from a guy they know, which resulted in your corporate network being placed on every RDNS blacklist on the planet. The one who doesn’t understand why when he sends an email, the customer doesn’t have it open to read before he lets goes of the mouse. The one whose laptop you secretly want to replace with an Etch-a-Sketch.

You know the one I am talking about… the one who just doesn’t “get” what you keep trying to tell him. I want you to share this blog post with him…maybe even forward it to him </wink>. This blog post is a list of seven things that non-technical folks should NOT do in email, unless of course, the objective is to lose customers and infuriate people.

1. Create form letters without testing them
   Here’s an example of something I got in my email today:
   
   And here’s the first thing I zoomed in on and clicked.
   
   If you are going to send out bulk email, either address it to “valued customer” so we’re at least honest about how impersonal it is, or test your program on your own personal account and a few of your cow-orkers before you fill your customers’ inboxes with junk.
2. Email an attachment that should have been the body of the email
   How many times have you gotten an email with an attachment and had to open the attachment to find that it either could have been incorporated in the body of the message, or left on a webserver and the email should have just included the link? That just wastes everyone’s time, and bandwidth, and also raises the chance your message will be blocked before the user even sees it.
3. Use a fixed width format that cannot be viewed on a mobile device
   If I have to scroll back and forth or pinch and zoom to read your message, I’ll probably just delete it unless it was something I specifically asked for. When you are trying to get your message out, make sure it can be received on any of the myriad devices your (potential) customers might use; full PC mail client, smartphone, e-reader, tablet, etc.
4. Use micro-fonts
   The saying is that 12 is the new 10. As devices get smaller, and as folks’ eyes get worse from staring at screens all day, one very bad thing you can do to people is make them squint to read your message. Yes, of course they can zoom in; but they could have also gone to your website instead of reading your email. Any extra effort or inconvenience is that much more reason for someone to delete you message unread.
5. Send read-receipt requested email
   If you want to know for a fact I got something, deliver it in person. Anything else is invasive and rude. When people do that to me internally, I make it a point to go over to their office and read the message out loud to them from my phone, asking for help with the big words. When sales people do it on unsolicited messages, I add them to the junk senders list.
6. Send an email to a large list of people where the only thing they have in common is that they’re in your address book or on your list
   It’s called BCC, and if you aren’t using it, you’re doing a huge disservice to your customers by exposing their information to people they’d just as soon not have their contact details. Hey admins? Why aren’t you limiting recipients per message to prevent the “mistakes” from happening?
7. Do not include your phone number in your email
   If you don’t want to take a customer call, you can always let it go into voice mail, but if you actually got our attention, and maybe we want to talk to you about what you’re selling, don’t make us hunt for your telephone number!

Readers, this is a chance for you to sound off about the things people do in email that drive you up a wall. Leave a comment (you don’t even have to register) and share your horror stories, pet peeves, or the worst affronts you’ve personally witnessed. Hello Internet, I’m listening.

How to Lose Customers and Infuriate People

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Gestures can replace passwords in Windows 8.

Why it has taken Microsoft so long to make password security more than an afterthought when it introduces a new operating system is anybody’s guess. Nevertheless, with Windows 8 it is making an effort to help users manage their passwords in an efficient and secure way.

Everyone has dozens of accounts they need for which they need to memorize passwords. Most people, though, only commit a few passwords to memory and just reuse them over and over again. A study in 2007, for example, found that the average Internet user had 25 accounts that required password access, but they only used six passwords to access their accounts.

Security pros decry the multiple use of passwords but there are plenty of sites on the web where if your password fell into the wrong hands, the consequences would be trivial. Reusing passwords for those sites should be acceptable. There are sites where unique passwords are a must, though, such as banking or credit card payment sites.

With Windows 8, Microsoft is addressing several nettlesome issues that discourage people from creating and using strong passwords. In the upcoming version of Windows, user names and passwords are stored in a secure location called the Credential Password Vault.

The latest version of Microsoft’s web browser, Internet Explorer 10, is designed to automatically access the Vault for your credential information, but other browsers and applications will eventually be able to access the area, too.

What’s more, if you have or obtain a Windows Live ID, you’ll be able to synchronize the Vaults across all your devices. Not only does that remove the annoying situation of trying to remember credentials for a site when you’re away from the device where you created those credentials, but it can provide a safety net should the password information on any one device be corrupted.

Synchronization appears to be pretty robust too. Microsoft says it can take place behind a firewall. However, websites can block the storage of credentials used to access them. Some banks do that. In that case, synchronization will not work because your credentials won’t be stored in your Vault.

Another intriguing aspect of the Credentials Password Vault is that it can also store security keys. Typically, those keys involve the use of hardware tokens to authenticate a person’s identity. The Vault, however, is designed to work with something called the Trusted Platform Module, which is being incorporated into more and more computers these days. The Vault and the Module, which acts as a virtual security token, can team up to perform the same function as token-based key pair system.

For tablets or computers with touchscreens, Windows 8 has an even neater password option. It allows you to take a photo of your choice and use it to access your slate by performing a series of gestures on it.

Although some security experts are skeptical of the method, and even Microsoft acknowledges that smudges on a screen could compromise the gesture password, the approach has the potential to be more secure than ordinary password schemes. Microsoft estimates that there are 398 trillion five gesture combinations that could be applied to a photo, compared to 182 million combinations for a five-character password and nine trillion combinations for an eight character one.

Windows 8 Offers New Password Features

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Whether you are troubleshooting an Exchange server performance issue, trying to see how well you sized your servers, or just want a better idea of what your users are doing, the Exchange Server User Monitor from Microsoft (or ExMon as it is known to its friends) is a great, free tool you can use to gather all sorts of information about your Exchange environment. The Exchange Server User Monitor has been around for years, and this latest version, 14.2.247.5, was released in December of 2011.

You can download ExMon from this link and use to evaluate a server, or an individual user’s interactions with that server. As with many tools from Microsoft, this has been around for years, but gets an update and a facelift every so often. With ExMon, you can view the following information:

• IP addresses used by clients
• Microsoft Office Outlook® versions and mode, such as Cached Exchange Mode and classic online mode
• Outlook client-side monitoring data
• Resource use, such as:
  • CPU usage
  • Server-side processor latency
  • Total latency for network and processing with Outlook 2003 and later versions of MAPI
  • Network bytes
  • And more.

The download is a simple MSI file that weighs in under 2MB in size, and the install is of the next agree next enter variety. You don’t need to run this tool on your Exchange server; It can run just fine on another server or on your workstation when you want to use it to view trace files gathered by the tool running on an actual Exchange server. Just launch it from the command line passing the ETL filename in the command, like exmon.exe c:\temp\exch01.etl [enter]. Note, if you are going to run the tool on your workstation, you can find it at C:\Program Files (x86)\Exchange User Monitor. There’s a reg file in that directory that you should import into your registry so the tool can work properly.

You can collect data for use with ExMon in one of three ways:

• Collecting data directly with ExMon
• Collecting data by using System Monitor (Windows 2000 Server and Windows Server 2003 only)
• Collecting data by using command-line tools.

Using ExMon directly to collect data is best done when you are looking to “spot check” a server and plan to gather data for only short intervals. ExMon trace files can become very large, especially when the monitor interval is long, and parsing these files can be both CPU and RAM intensive.

For trending data, it’s best to use System Monitor, and schedule it with a reasonable sampling frequency. It’s best to start out small, monitor the size of the files generated, and adjust your sampling interval and the duration of your monitoring as you see fit.

While the documentation has not been updated yet for this version, you can read more about how to use ExMon at the TechNet site: http://technet.microsoft.com/en-us/library/bb508855(EXCHG.65).aspx.

Cool Tools: Microsoft Exchange Server User Monitor

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

When starting out, many small businesses set up their email using one of the free accounts available to them. Services like Gmail by Google, Hotmail from Microsoft or Yahoo!’s mail service, provide a working email address with almost no maintenance for a business just getting its feet wet.

However this may not be the best way to make a first impression with your potential customers.

Listed below are seven reasons why you need to ditch the yourcompany@freeemail.com and go with an address that better reflects the image you want your company to have.

1. Free email looks less professional

People associate free email services like Gmail or Hotmail as a personal accounts. Businesses, on the other hand, should have an email address that looks more professional. In fact, a study by Visible Logic in Amsterdam found that 70 percent of people view email messages coming from free email services as less professional when used by a business.

2. Free email looks spammy

Over the years, people have been burned so often by spam that they have become very adept at spotting shady looking emails in their inbox. One way to spot an email that may have malicious intent is by looking at the address. If you email address doesn’t look legitimate, your messages may be overlooked by overly cautious recipients.

3. Free email looks cheap

When people receive an email from your company and it has the @freeemail.com trailing it, your company looks cheap. For less than five bucks a month, you can set up an email address with your company’s domain. Sometimes you can even get a few of these for free when you host your company’s website. Customers who see that you are unwilling to spend a few dollars on this are often left to wonder what else your company may be skimping on.

4. You lose credibility when you use free email

A legitimate, professional looking email address tells your customers that you are here to stay.

Not only that, but having multiple email addresses such as: info@yourcompany.com, sales@yourcompany.com or service@yourcompany.com shows others that you are a well structured organization. The impression one gets when there is one, free email as the sole contact is that one person is handling everything for a company. This may scare larger clients away for fear that the company cannot handle their needs.

In today’s business atmosphere, trust is everything. Especially when it comes to online sales. Every little thing your company can do to establish trust and credibility will help your business grow.

5. Free email is less secure

Remember the old saying: there is no such thing as a free lunch? Well that applies to email as well.

True, Google, Yahoo!, Microsoft and the other free email providers do everything they can to make sure that their email services are as secure as possible, but things can slip through the cracks.

To pay for “free” email, users are subject to advertisements. While these help pay for the servers and storage space, they also have been linked to spam and hijacking. There have been several cases where businesses have had bank accounts and other confidential information compromised by cyber criminals who intercept email messages of companies that use free email services.

6. Free email may put you out of compliance

Nowadays, there are regulations and laws that govern so many industries and their record keeping that many large companies have entire legal teams dedicated to just compliance related issues.

But smaller companies are not immune to compliance. Companies of all sizes need to be aware of HIPPA when it comes to healthcare, PCI DSS when dealing with credit cards, and CAN-SPAM Act when it comes to marketing.

Free email likely does not offer you the tools required to be in compliance with any of these, or the many other, laws or regulations for email use.

7. You miss out on marketing your brand

Having your website’s domain name in every email you send out gives you the opportunity to build your company’s brand. Info@yourcompany.com puts your web site address in the minds of your customers. They know where to turn to when they need your services because they are so used to seeing your domain in every communication from you.

7 Reasons to Ditch That Free Email Address

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

BYOD can give administrators a headache.

More and more organizations are finding their employees using personal devices to access company data. Without some measure of control, those workers can create serious security problems for their employers.

As much as some administrators would like to block the use of personal devices in the workplace, that’s unlikely to happen for a number of reasons. For example, many employees are already using their own devices at work, as a recent survey by IDC shows. That poll found that 95 percent of workers use one personally purchased device on the job.

In addition, businesses are demanding more and more productivity from their workers, and that’s what they can get by allowing employees to use their own gadgets for work. One study by iPass, for instance, showed that employees using personal devices worked 240 more hours a year.

Not many companies would want to part with that kind of productivity, and they’re not going to, according to a Gartner analysis. To do so, that report noted, corporations will be embracing the practice by placing their apps on their workers’ devices. In fact, by 2014 Gartner predicts that 90 percent of all employee-owned devices will have corporate apps running on them.

Other cultural and technology trends are also making opposition to the Bring Your Own Device futile. Hardware makers are finding they need to produce products with a consumer bent if they want to stay in business.

Virtualization and cloud computing encourage access to corporate technology resources whenever worker wants to access them and with whatever they want to access them with.

Meanwhile, as the line between work and non-work becomes more and more obscure, the case for creating a clear line of demarcation between work and home devices becomes weaker and weaker.

To address issues created by the use of personal devices in the workplace, companies have begun to adopt BYOD policies. Before adopting such a policy, here are some questions an organization might want to consider.

• Should data be classified to determine what can and can’t be downloaded by personal devices?
• What happens to company data on a personal device when an employee leaves the company?
• What happens if a personal device is lost or stolen?
• Do personal devices need to be configured in any special way?
• How can an acceptable password policy be implemented on a personal device?
• What forms of encryption should be acceptable?
• What personal devices are acceptable for use with corporate resources?
• Should employees be allowed to jailbreak or root their devices, as doing that may make the device more susceptible to security risks.
• Should employees be required to sign the BYOD policy before they’re granted access to the company’s network?

Some of those questions were considered by Unisys when it formulated its BYOD policy. Among the requirements of that policy is that Unisys has the right to confiscate a device if it’s needed for litigation purposes.

That policy requires employees to accept a digital certificate to be installed on their personal device. It authenticates the device to Unisys’s systems, and it allows the company to analyze access behavior. Knowledge of that behavior can be used to identify abuse of access privileges.

The certificate gives an employee access to email and calendar functions on the system. Access to other functions can require additional authentication.

Another requirement of the policy, and one most administrators will find desirable, is the installation of a program on the device that enables all data to be remotely wiped on a unit that is lost or stolen.

What Should Be in Your BYOD Policy?

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators