Tag: microsoft

Monthly Link roundup – November 2015

You can sign up below to receive the list by mail as it’s compiled each month



 

Messaging

Modern Datacenter

Azure

DevOps

Understanding the Microsoft Support Lifecycle

As a consultant, I am often put in the position of reminding customers to be conscious of support lifecycles when making strategic decisions on upgrades and internal product lifecycles, today I was asked to help a customer plan a migration from Exchange 2003 to Exchange 2010, and I felt I should write a little bit about this, given that Exchange 2010 just exited mainstream support.

Microsoft itself has a very detailed set of lifecycle guidelines laid out here, but there is some understandable confusion by many, as to what this actually means for them

There are three main phases to the support lifecycle, Mainstream Support, Extended Support and Service Pack Support.  Each of these phases has a set of guidelines defining their duration, and the type and availability of various support during each phase.

Mainstream Support

This is generally the important one, and the one that most people associate with the general supportability of a product in broad use, it starts when the product ships, and MS guarantee this phase for a minimum of five years (at the current service pack level) for Business, Developer and Desktop Operating System products.  This guarantee is different for hardware and consumer software products

Extended Support

This phases is also guaranteed for a minimum of five years (bringing the support window to a total of 10 years) for Business, Developer and Desktop Operating system products, but it has some caveats.

In extended support the limitations include

  • no longer request changes / features to a product
  • non-security hotfixes limited to customers with an extended hotfix support plan
  • no complimentary support

The good thing is, your product is still supported, which is great for organizations not agile enough to upgrade frequently, or with 3rd party tooling that hampers platform upgrades from occurring in a timely fashion.  The real world consequences are that the product becomes more complicated and expensive to support, increasing its overall lifecycle operational expense (OPEX) and diminishing it’s ROI over time.  This isn’t necessarily a bad thing, if you are aware of this from the outset and fit it into your calculations, your product is still valid, will still receive critical security updates, and support can still be acquired for a cost.  At this point in a products lifecycle, I can’t however recommend you move to it, it’s already on the way out, and likely has one or two successors in play, and you should weigh the considerations out very carefully.

Service Pack Support

This one can get a bit confusing, it does not replace mainstream or extended support, but when a new service pack is released, for the majority of products, Microsoft will provide support for the previous version for 12 months (24 for Dynamics and Client & Server Operating Systems), what this means is that while your product is still in support, if you are on an out of date service pack (older than 12 months) you don’t actually meet the requirements to receive certain support, and the first suggestion is going to be ‘make sure you have the latest service pack’

Microsoft also no longer release features or updates for platforms running older service packs (you should still see security updates though).

In the event that a service pack is the final service pack of a platform, the rules governing mainstream and extended support apply, take the example below

2015-01-27_14-09-14

Exchange 2010 was released on November 9th 2009, starting the support lifecycle counter

Service Pack 1 for Exchange 2010 was released August 23rd 2010, starting the 12 month countdown for RTM to fall out of support, if after ~August 23rd 2011 (exact dates vary) you still had RTM in play, you were out of support and would see limited availability of builds after this (in fact, the last roll up update for Exchange 2010 RTM was December 2010)

Service Pack 2 for Exchange 2010 dropped on December 4th 2011, starting the count down for SP1 support to end twelve months hence, and sure enough the last roll up for Exchange 2010 w/SP1 was December 10th, 2012

As Service Pack 3 was the final Exchange 2010 service pack, released on February 12th 2013, it remains supported until mainstream, and then extended support end, albeit with the caveats mentioned below. As long as you are running SP3 on Exchange 2010, you will have extended support until 2019, however Mainstream support ended for this product January 13th 2015

Hopefully this helps tables such as this one below, make a little more sense, and with Windows Server 2008, Windows Server 2008 R2, Windows 7, Exchange 2010, and Unified Access Gateway 2010, all exiting mainstream support this year, as well as the end of extended support for a number of well deployed platforms, It’s a good time to understand your support lifecycle information, and plan accordingly.

2015-01-27_14-00-54Exchange lifecycle information from the Microsoft lifecycle portal

 

 

Exchange 2010 Namespace considerations

For some of us, migrating from Exchange 2003 to Exchange 2010 is an exciting concept, with tons of new features, simpler high-availability features and a lot more power for the users

One of the common overlooked design pieces of a Microsoft Exchange 2010 architecture is the namespace considerations

Legacy Environments

for most Exchange 2003 environments the following names are usually in play

  • mail.mydomain.com – MX Record, mail flow
  • webmail.mydomain.com, OWA, OMA, EAS, (Web Services) – Certificate Name

This is not always the case, some people will just use mail.mydomain.com for everything, and this also works great.  Your edge configuration will apply certain requirements/restrictions on how you configure your existing namespace, but this is all relatively simple in Exchange 2003 compared to some of the considerations in Exchange 2010.

Exchange 2010

Most organizations are deploying Exchange 2010 in a highly available configuration, and many are implementing site resilient considerations also, this can lead to a complex namespace design that should be carefully considered and design before the first server is deployed in your organization.

Some things to consider in Exchange 2010 from a high availability standpoint are

Internet Presence

  • webmail,mydomain.com – Primary point of presence, OWA, OA, EAS, OAB – Certificate Name

Auto discover Service

  • autodiscover.mydomain.com – auto configuration URL– Certificate Name

Client Access Arrays

  • site-casA.mydomain.com – Internal AD reference to CAS Array for each site
  • site-casB.mydomain.com – Internal AD reference to CAS Array for each site
  • casA-nlb.mydomain.com – Assigned to VIP of Load balancer for HA CAS – Certificate Name
  • casB-nlb.mydomain.com – Assigned to VIP of Load balancer for HA CAS – Certificate Name

Co-Existence

  • legacy.mydomain.com – Name used for redirection to 2003 during migration – Certificate Name

Site Resiliency

  • webmail2.mydomain.com – alternate internet pointe of presence– Certificate Name

Failback URLs

  • failbackA.mydomain.com – DNS Failback URL for timeout consideration – Certificate Name
  • failbackB.mydomain.com – DNS Failback URL for timeout consideration – Certificate Name

As you can see there is a lot to consider here before jumping in and throwing some servers up, and some of these names may not be required, or can be consolidated with others depending on your edge topology

For more detailed information on namespace design please check out the TechNet article located here

The Power of Community – Usergroups

Some of you will know that I am active in a number of regional user groups, in fact, some of you may have found me or my blog by attending one of the events I have spoken at or helped co-ordinate.

The Boise user group scene has kind of dried up over the last few years and I endeavor to help change that.  It was always a goal of mine to have an active and vibrant forum for local users to network and discuss topics of interest, and while we are served very well by the local VMware user group (with over 100 people in regular attendance) I feel the general IT scene is underserved still

Recently I assisted Jeff Wilding and some Microsoft Staff kick off the Boise Microsoft Unified Communications User Group by presenting a piece on Exchange migrations and some of the considerations to be made in this space.  After assisting him with preparations, and giving my presentation I was asked if I would be interested in taking a larger role in future events and I have committed myself to helping this group succeed.

I also feel now would be a great time to get the Boise IT Pro User Group back up and running with a regular schedule, and with such a broad focus the topics could be endless

If you, or someone you know are interested in this space, and helping out the local IT community do not hesitate to get in touch with Jeff Wilding, Mark Rezansoff or myself

Regional Groups

You will notice a new page listed at the top of my blog that will display the most current info I have on a number of regional user groups that I have participated in, as well as any other prudent industry events that may be of interest

Forefront Unified Access Gateway 2010, what’s that then?

I keep hearing a lot of confusion as to what UAG is, where it fits, and what it does, so here is a brief introduction to what it does, and what it’s capabilities are.
Forefront Unified Access Gateway 2010 is designed as a gateway into your organization, and utilizes a number of other Microsoft components to enable a seamless and integrated experience for both corporate users, and 3rd parties

  • UAG is NOT the same as TMG, nor are the two interchangeable
  • UAG is geared toward securely allowing inbound access
  • TMG is geared toward protecting internal users from external threats
UAG vs TMG

A lot of confusion arises because UAG installs some TMG components and utilizes them, mainly for array management and firewalling, it cannot however operate as a forward or reverse proxy, nor can it do web filtering or use the active protection components that TMG does

The TMG components built into UAG are there to protect the TMG server, as it is generally afforded a global external address and does not sit behind its own firewall due to the NAT restrictions if you wish to utilize DirectAccess

Direct Access

Microsoft DirectAccess technology allows you to bridge the connections of enterprise endpoints to the corporate network whenever they are online, this is accomplished seamlessly and securely with a combination of IPv6, PKI and IPSEC technologies.  This allows users to access resources on the corporate infrastructure safely from anywhere they can get online, as well as providing internal support staff access to roaming systems without requiring them to join special support sessions, install special software, or have the user bring the system into an office

DirectAccess is a technology built into Windows 2008 R2, and can operate without UAG, however there are significant benefits to deploying direct access through a UAG system, including DNS64 and NAT64, both of which are required to allow seamless network access to IPv4 only corporate resources (not just IPv6 ready apps)

Remote Access

UAG provides a user web portal to access applications, services and network resources, as well as integrating with an RDS gateway component if you chose to install that, this portal provides access to numerous devices and can detect the type of device, and the type of experience to deliver.  These portals can be customized to fit the clients needs, to display client assets and specifics on a case by case basis

UAG is also capable of VPN termination, this can be via integration with RRAS for PPTN and SSTP tunnels, or via native UAG SSL VPN capabilities

While TMG can also do VPNs, it is not afforded the same SSL VPN capabilities that UAG has, this is another UAG plus point

Server Publishing

UAG is the Microsoft recommendation for publishing Microsoft server resources, this is a shift from IAG2007 when MS still pushed ISA2006 as it’s best practice method for securing Exchange and SharePoint web interfaces.  If you wish to make services such as outlook web access, outlook anywhere, active sync and SharePoint sites available to your users over the internet, this is the technology to deploy to secure and manage access to those resources.

TMG can still handle this, but many of the upgrades and features that have been added to UAG2010 have not been included in TMGs publishing capabilities, so when publishing SharePoint, Exchange, or even RDS Web Access, UAG is the way to go (reverse proxy requirements are still handled by TMG 2010, this includes OCS and Lync requirements)

Licensing

UAG has client and server CAL requirements, unlike TMG which is licensed as a server (unless you want all the filtering and protection suites), however ECALS have UAG CALs included, this is good to know for ECAL customers as the majority of the cost is already paid for and you can start benefiting from the technology straight away through a pilot, or implementation engagement