Michael Sneeringer's Blog

ExtraTeam is hiring!

2010-11-22T20:17:00.000-08:00

Senior Systems Engineer @ ExtraTeam

We tend to assume success, and for good reason. We’ve built a bleeding edge technology organization from the ground up. Each and every day we receive validation on our immense value to the world in strategizing and deploying the best of the best technology solutions. Our Microsoft practice has more than doubled over the past year and we continue to expand at a breath-taking pace. You will be joining the top Microsoft consulting team in the Bay Area; our team consists of Microsoft Certified Masters, MVP's, and published authors.

This is high-performanceville and we just can’t wait to have you here.

Standard description to an exceptional opportunity

This is a fast moving job where you will be working on all the latest technology from Microsoft.

Typical projects you will be working on include designing, deploying and maintaining;

• Exchange 2010 including Unified Messaging
• Lync 2010 with full voice and video integration
• System Center Operations Manager 2007 infrastructure and advanced authoring
• System Center Configuration Manager 2007 infrastructure and OS Deployment
• Hyper-V, Forefront, Active Directory, and everything in between

Job Responsibilities:

• Designing: Work closely with our customers to assess their needs and design appropriate solutions as well as being an evangelist for ExtraTeam.
• Implementing: You will be part of a high level team responsible for meeting our customers' implementation, configuration, installation and management needs.
• Presenting: Be able to present product and technology information to all levels within an organization (both pre- and post-sales) as well as at seminars and trade shows.
• Troubleshooting: Work closely with customers to resolve networking problems across a wide range of technologies.
• Documenting: Ensure high quality technical documents are produced quickly and accurately.

Our customer base is a very diverse mix including many household names, defense contractors, retail giants, leading pharmaceuticals as well as local government and education.

Although technical expertise is key, your attitude and aptitude will be far more important. We're looking for someone with a strong desire to learn from the best, as part of our tightly-knit team.

We are a long standing Microsoft Gold Partner as well as a Cisco Gold Partner.

What's in it for you:

• Strong base salary, quarterly bonus, benefits, 401K, and much more.
• Stable, fun, and team-oriented work environment.
• Opportunity to achieve the latest and greatest certifications, including Microsoft Certified Master
• Opportunity to innovate with the latest tools at your disposal.
• Opportunity to work remotely on select projects
• Opportunity for growth. This is a full-time, permanent position. We're thinking long term.

Requirements for you to meet your potential:

• Microsoft MCITP certification or better.
• You will need to be a specialist/expert in multiple Microsoft products
• You will need to be able to handle multiple projects concurrently and drive them to completion (yes, we're very busy)
• Cisco certification would be desirable

Send resumes to jobs@extrateam.com

Load Balancing Exchange with Barracuda

2010-06-09T15:01:00.000-07:00

Barracuda recently put out a whitepaper on how to load balance Exchange 2010:

Download it here

There is a key piece missing from this document - if you want to do "Layer 7 - HTTP" load balancing with "HTTP Cookie" persistence (Microsoft's recommendation for OWA), you need to select SSL Offloading and configure your nodes to use port 80.

Otherwise, you will need to use TCP or TCP Proxy (depending on whether you're in a 1-arm or 2-arm configuration) for all services including OWA.

Exchange Unified Messaging 2007 / 2010 Co-Existence

2010-05-02T10:07:00.000-07:00

In a Unified Messaging co-existence scenario with Exchange 2007 and Exchange 2010 - the migration path is to configure Exchange 2010 as the next hop from the PBX. If a call comes in that is destined for an Exchange 2007 user, Exchange 2010 will redirect the PBX to establish a connection with the Exchange 2007 server.

Here is a basic flowchart of how this works:

Looking at the SIP trace in Netmon, Exchange 2010 is sending the PBX a "302 Moved Temporarily" message:

Notice that the Contact field (the field that tells the PBX which server to redirect the call to) is using the FQDN of the Exchange 2007 server and not the IP address.

If the PBX cannot resolve the Exchange 2007 server via DNS (or some kind of host file), your call will be dropped.

Exchange 2010 Master Certification

2010-03-30T11:41:00.000-07:00

I recently became Microsoft Master certified for Exchange 2010. I am, as of this writing, the only person in the world that is Master certified on Exchange 2010 and Office Communications Server 2007.

Click here for the official announcement

Polycom CX300

2010-02-13T11:24:00.000-08:00

The Polycom CX300 USB phone for OCS started shipping a few weeks ago and I was one of the early adopters, happily replacing the old CX200 "Catalina" model that I had been using.

Link to CX300 on Polycom website

The good:

The handset has a much more natural shape and is much less bulky than the triangular mouthpiece featured in the CX200 and CX700 models.
The display shows the user name, presence, time, and date. When I receive a call, it shows the name and title of the caller.
The quality of the speakerphone is much improved over the previous models.
When I get a new voicemail, there is a small red light that turns on
There is a number pad and buttons to hold and redial
The price is right, $135 now at Amazon

The bad:

I've noticed some quirky behavior with normalization and dialing from the number pad
It's a USB phone, so call quality could be an issue if I am heavily utilizing my PC and of course I can't reboot during a call

Overall:

This is the first time that I have felt comfortable recommending an OCS desk phone to my customers. Previous models had some serious deficiencies - the CX200 did not have a number pad and the CX700 was too expensive with a lackluster touch screen.

The CX300 is ideal for a home office, since it works fine for remote users and does not require a VPN. It also works great for users that frequently travel for long stretches and want to set up a basic office on the road.

One of the big drawbacks with recommending OCS as a PBX replacement has been the lack decent options for a desk phone. While a headset and keyboard are fine for technical users, the vast majority of the population expects to have something resembling a traditional phone on their desk. Finally there is a solid option for OCS at a great price point.

Exchange 2010 - High Availability and Disaster Recovery With Only 3 Servers - Part 2

2010-01-21T15:44:00.000-08:00

Background

One of my customers wants to know how to leverage Exchange 2010 to provide high-availability (server failure) and disaster recovery (site failure) using the minimum number of servers. Here is a walk-through of the reference design and site fail-over experience:

Production Site:

DC (FSW)
Hardware Load Balancer (VIP for CAS Array)
EX2010-1 (CAS/HTS/MBX Roles)
EX2010-2 (CAS/HTS/MBX Roles)

DR Site:

DC-DR (Alternate FSW)
EX2010-3 (CAS/HTS/MBX Roles)

Configuring Disaster Recovery with one additional Exchange 2010 Server

The first step is to configure my DAG to handle a site failure. This entails setting the DatacenterActivationMode to DagOnly and adding an Alternate File Share Witness using the AlternateWitnessServer and AlternateWitnessDirectory attributes. Setting the DatacenterActivationMode to DagOnly is required so that I can manually modify the DAG and to prevent split-brain when the Production site is restored.

At this point I will simulate a site failure by shutting down all of the servers in my Prod site (DC, EX2010-1, EX2010-2, and my hardware load balancer). In a 3 server DAG, cluster quorum is maintained by a node majority - so at this point with two nodes offline the remaining server cannot hold quorum and therefore my database is dismounted and cannot be re-mounted.

My Outlook clients are all showing as Disconnected.

In order to restore service, I must first get my database mounted. To do this I first need to stop my DAG for my Prod servers using the Stop-DatabaseAvailabilityGroup cmdlet.

Next I will need to stop the Clustering service using the Services snap-in.

Next I will need to restore my DAG for my DR site using the Restore-DatabaseAvailabilityGroup cmdlet.

At this point I can now mount my database in my DR site.

Although my database has been mounted, my Outlook clients are still offline because they are pointing to my hardware load balancer which is in a failed state. I can restore service to my clients by updating the DNS entries for internal.test.local and external.test.local to point to EX2010-3. Shortly thereafter my Outlook clients will be able to reconnect.

Failing Back to the Production Site

When my production site comes back online, I will want to fail-back. Fortunately this process is fairly easy (provided that I don't have to re-seed my database replicas).

Once my Production site is back online, my servers will start synchronizing with the active replica on EX2010-3.

After that process is complete, I can re-start my DAG using the Start-DatabaseAvailabilityGroup cmdlet. Note that all of the Exchange servers are now populated in the StartedMailboxServers field.

At this point I can now re-activate my database on EX2010-1 and update my DNS records to point to my VIP for internal.test.local and external.test.local.

Exchange 2010 - High Availability and Disaster Recovery With Only 3 Servers - Part 1

2010-01-21T13:59:00.000-08:00

Background

DC (FSW)
Hardware Load Balancer (VIP for CAS Array)
EX2010-1 (CAS/HTS/MBX Roles)
EX2010-2 (CAS/HTS/MBX Roles)

DR Site:

DC-DR (Alternate FSW)
EX2010-3 (CAS/HTS/MBX Roles)

Configuring High Availability with two Exchange 2010 Servers

I am going to assume that you are already familiar with the process of installing Exchange, creating a DAG, and creating a CAS Array - so here is an overview of the configuration:

All three servers are added to my DAG and I set the Domain Controller as the File Share Witness (note: since there are three servers in my DAG, it will use a Node Majority under normal circumstances).

Next I configured my database to replicate to all of the members of my DAG.

Next I created a Client Access Array in the Exchange Management Shell and assigned it to my database.

Next I created a VIP on my hardware load balancer. I used a Barracuda 340 - but really any HLB should be fine.

Next, I created DNS records for the VIP on my hardware load balancer. I used two addresses: internal.test.local and external.test.local

Finally I configured the InternalURL and ExternalURL on my Exchange Virtual Directories to point to my VIP.

What happens during a Server Failure

At this point I now have high availability within my production site that can tolerate the failure of either EX2010-1 or EX2010-2.

At this point, DB1 is mounted on EX2010-1. When I look at my Connection Status in Outlook, it shows that I am connected to the VIP (in this instance, I am actually connected to EX2010-1 via the load balancer).

If I decide to do a graceful fail-over my database to EX2010-2, my Outlook Clients will receive a notification that they will need to restart Outlook. Note that even after the fail-over I am still using EX2010-1 as my RPC Client Access Server via my hardware load balancer.

If I decide to do a fail-over of my RPC Client Access Server from EX2010-1 to EX2010-2 (via marking EX2010-1 down on my hardware load balancer), my Outlook client will briefly lose connection before it is able to successfully reconnect.

In the event that I had a non-graceful server failure, my Outlook client would briefly lose connection before reconnecting (and possibly prompting my to restart Outlook).

Client Version Filtering on Windows x64

2010-01-10T14:21:00.000-08:00

At my company we use Client Version Filtering to deploy the latest Communicator client updates. Here is how it is configured:

After installing the January updates for Office Communications Server 2007 R2 and publishing the new Communicator update to Client Version Filtering, I received an error that my client could not find the update.

I looked in the IIS logs and noticed that it was trying to pull the update for the x64 architecture.

2010-01-10 21:11:12 192.168.200.151 POST /AutoUpdate/Ext/Handler/OCUpgrade.aspx folder=OC&lang=1033&mode=non-ui&arch=x64&flavor=pm&build=fre 443 - 192.168.200.70 Microsoft+Office+Communicator/3.0 401 2 5 596

Even though my Communicator client is x86, I am running Windows 7 x64.

I created a new folder for x64 in the AutoUpdate path as pictured below:

Subsequently, my client was able to download and install the new Communicator update.

2010-01-10 21:34:53 192.168.200.151 HEAD /AutoUpdate/Ext/Files/OC/x64/fre/1033/Communicator.msp - 443 - 192.168.200.70 Microsoft+BITS/7.5 401 2 5 63

Although this is an acceptable workaround for now, my assumption is that this is actually a bug that will need to be addressed by Microsoft. Most likely this logic was put in place for a forthcoming x64 version of Communicator.