Microsoft Product Life cycle

A typical Microsoft product life cycle lasts 10 years from the date of the product’s initial release. The end of this life cycle is known as the product’s end of support. This means Microsoft will no longer provide updates or support of any kind.

End of support can result in vulnerabilities that impact your infrastructure and data.

 

End of Support

Mainstream support for Exchange Server 2010 ended in January 2015. Per standard practice, Microsoft’s extended support ends five years after mainstream. The original end of support date was in line with the end of support for Windows 7 and Windows 2008 server. This occurred on January 14, 2020. However, to allow businesses time to complete their migrations, it was extended to October 13, 2020.

Mainstream support for Office Suite 2010 is also ending on October 13, 2020. This leaves approximately 3 months to find the right path for your organization and implement the migrations.

 

End of Support Implications

• So Long Security Updates – Critical components like bug fixes and security patches that protect users and data will discontinue. Without these updates, the risk of ransomware or malicious attempts to access information rises.
• No More Support – The first thing Microsoft support will tell you when you attempt to open a new case is, sorry, that version is no longer supported. We cannot help.
• Goodbye Support Documentation Updates – While existing articles will still be available, new best practices and guidance will no longer continue to be published for those versions.
• Hello Compliance Issues – Running outdated or unsupported products can be an immediate ticket out of compliance. If your industry or regional standards are dependent on regulations, you may be introducing a legal problem if you stay put.
• No More Bug Fixes – With the discontinuation of bug fixing, you can expect to see the introduction of stability and usability issues.
• Accept Risks with Unsupported Versions – There are risks of downtime and productivity loss from server failure. It could end up costing you money in addition to headaches.

 

What will happen on October 14, 2020?

If you are on these versions of Microsoft software, they will continue to run. However, there will be some very good reasons to be concerned when staying on these platforms:

1. Compatibility – Assuming you’re Exchange Server 2010 is running on a compatible Microsoft Windows Server OS, updates to the OS may not be compatible with Exchange Server 2010. Making it very possible that an OS update could cause Exchange Server to cease to function. So, you will be limited to what updates you can install from the OS perspective.
2. Security – Vulnerabilities are discovered and released daily. After October 13, Microsoft will not release security patches to address the new vulnerabilities for Exchange Server 2010 and Office Suite 2010. This means a new vulnerability may or may not work in Exchange Server 2010 or Office Suite 2010. Microsoft will not care. Be sure that the cybercriminals will be testing out the new vulnerabilities on the older versions.
3. Compliance – New government regulations around protecting data are getting specific around what kinds of IT controls need to be in place. For example, PCI requirements state “Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. Deploy critical patches within a month of release.”

 

Options – Exchange Server 2010

 

• Migrate to Exchange Online (Office 365) – This is the preferred path by most organizations. By upgrading to Office 365, you have the latest version of Exchange in addition to all the functionality, collaboration, and applications without maintaining on-premises hardware.Microsoft provides one of three types of migration scenarios:
  
  1. Cutover: (for smaller orgs) Where everything is migrated and on-prem services are shut down.
  2. Minimal Hybrid: Similar to cutover, but when you have so many mailboxes you need a bit of time but without any of the hybrid environment features.
  3. Full Hybrid: Where you have lots of mailboxes and need to be hybrid for an extended period of time while you migrate. This is also clearly the preferred option from Microsoft’s end.

From feature enhancements to recent announcements of price hikes for on-prem software, Microsoft continues to push organizations off-premises and into the cloud suite. Support is available for all of Microsoft’s cloud offerings.

 

• Remain On-Premises and Migrate to a Supported Version of Exchange – Moving email to the cloud may not be possible for business reasons. By migrating to a newer instance of Exchange, your organization has protection against the implications of an out-of-date server. Microsoft has 3 versions of Exchange Server remaining under support after October 13, Exchange Server 2013, 2016, and 2019. All are viable choices to remain on-prem (Exchange Server 2013 is slated for end of support 4/2023). Microsoft recommends at least Exchange 2016 as 2013 has limited functionality compared to Office 365. Keep in mind, there is no upgrade path for Exchange Server. A new Exchange environment will need to be stood up. Then a migration occurs to move the mailboxes and data. Support is not available with Microsoft’s on-prem offerings.

 

Whichever option one chooses, the plan should be simple and effective.

1. Decide on a path – Determine whether to update to a newer version of Exchange Server or move to Office 365 (or another platform if desired).
2. Assess Mailbox Usage – How many mailboxes and how much space are they taking up?
3. Determine Migration Strategy – whether on-prem or cloud.
4. Assess Archive Options – will archiving help depending on length of time email has been around and the amount of space.
5. Archive – archive any data fit for archiving
6. Migrate – whether on-prem or cloud.

 

Options – Office Suite 2010

Microsoft has also been making a push to Office 365 here as well. There are fewer feature updates and enhancements for Office Suite 2019. A recent 10 percent price hike has occurred. It has a shorter extended support life than prior versions of Office Suite.

Both versions of Office Suite 2019 (Cloud or On-Prem) require Windows 10.

Migrate to Office 365

• Subscription based service with a license tied to a subscription few based on the amount of users
• Upgrade options with a variety of available plans to tailor usage to user needs.
• Regular feature updates to keep current with Office features, tools, and bug fixes alongside security updates to keep protection up to date and safe from hackers.
• Built in cloud storage capabilities with Microsoft OneDrive.
• Support window that will exist as long as the Office Suite does.

Remain On-Premises and upgrade to Office Suite 2019

• One-time purchase sold on a per computer perpetual license.
• No upgrade options for future releases.
• No feature updates from initial release.
• Security updates to keep protection up to date and safe from hacking.
• Five-year support window that ends in 2025.

Conclusion

Office Exchange Server 2010 and Office Suite 2010 end of life is an inevitability all users must face. With a little less than 3 months remaining, now is the perfect time to figure out which of Microsoft’s options are best. Then, start the groundwork for migration. Deciding whether Office 365 is right for your organization will depend greatly on your needs. Whatever your requirements, making an informed decision will ensure an ease of transition and applications that are optimal for use.

Contact Zunesis for an assessment on what Microsoft option is best for your organization.

 

So, you think you’re ready for the jump to Office 365?  You have done your research; licensing, cost-savings, administration, migration strategies, best practices, etc. You have weighed the costs of doing the migration in-house or choosing a vendor to assist. What’s next?

 

Ensuring a stress-free migration for you and your users will need 3 things:

 

• Smart planning
• Smart decisions
• Time

 

There are many things recommended to make the migration go smoothly. One key piece of smart planning is ensuring the Active Directory accounts, which are migrating to Office 365, are prepared for the migration. Successful directory synchronization between your on-premise directory and Office 365 requires that attributes are properly configured.

 

The following 5 tasks should be completed in Active Directory to plan for a smooth migration:

 

1. Active Directory Cleanup Tasks

 

Perform the following cleanup tasks in your on-premise directory:

• • Ensure that each user has a valid and unique email address in the proxyAddress Field
  • Remove Duplicates in the proxyAddress field
  • Ensure each user has a valid and unique value for the userPrincipalName atrribute in the user’s user object
  • For best use of the global address list (GAL), be sure the information in the following attributes is accurate:
    • givenName
    • surnamedisplayName
    • Job Title
    • Department
    • Office
    • Office Phone
    • Mobile Phone
    • Fax Number
    • Street Address
    • City
    • State
    • Zip
    • Country

 

 

2. Directory Object and Attribute Preparation

 

Directory synchronization will fail if some of the Active Directory users have one or more duplicate attributes. If there are duplicate values, the first user with the value is synchronized. Subsequent users will not appear in Office 365. The following attributes should need prepared:

• • 1. • • • Mail
             • Attribute must be unique within the directory
           • mailNickname (Exchange alias)
             • Cannot begin with a period (.).
             • Attribute must be unique within the directory
           • proxyAddresses
             • Can accept multiple values
             • Value must not contain a space
             • Attribute must be unique within the directory
             • Invalid characters:
               • [ \ “ | , / : < > + = ; ? * ]
             • sAMAccountName
               • Maximum characters: 20
               • Attribute must be unique within the directory
               • Invalid characters:
                 • [ \ “ | , / : < > + = ; ? * ]
               • targetAddress
                 • Maximum characters: 255
                 • Value must not contain a space
                 • Attribute must be unique within the directory
                 • Invalid characters:
                   • [ \ “ | , / : < > + = ; ? * ]
                 • All SMTP addresses should comply with email messaging standards
               • UserPrincipalName
                 • Must be in the Internet-style sign-in format: joe@contoso.com
                 • Invalid characters:
                   • [ \ “ | , / : < > + = ; ? * ]
                 • The @ character is required in each value
                 • The @ character cannot be the first character
                 • The user cannot end with a period (.), &, a space, or @
                 • Routable domains must be used, local or internal domains cannot be used

 

3. Prepare the userPrincipalName Attribute

 

Active Directory is designed to allow the end users to sign in to the directory by using either sAMAccountName or userPrincipalName. End users can sign in to Office 365 by using the user principal name (UPN) of their work or school account. Directory synchronization attempts to create new users in Azure Active Directory by using the same UPN that’s in the on-premises directory. The UPN is formatted like an email address. In Office 365, the UPN is the default attribute that’s used to generate the email address. It’s easy to get userPrincipalName (on-premises and in Azure Active Directory) and the primary email address in proxyAddresses set to different values. When they are set to different values, there can be confusion for administrators and end users.

 

4. Add an Alternative UPN Suffix (if needed)

 

There may be a need to add an alternative UPN suffix to associate the user’s corporate credentials with the Office 365 environment. A UPN suffix is the part of a UPN to the right of the @ character. UPNs can contain letters, numbers, periods, dashes, and underscores, but no other types of characters.

 

5. Match the On-Premise UPN with Office 365 UPN

 

If directory synchronization is already setup, the user’s UPN for Office 365 may not match the user’s on-premise UPN that’s defined in the on-premise directory service. This can occur when a user was assigned a license before the domain was verified. To fix this, use PowerShell to fix duplicate UPN to update the user’s UPN to ensure that the Office 365 UPN matches the corporate user name and domain. When updating the UPN in the on-premise directory service and to have it synchronized with the Azure Active Directory identity, remove the user’s license in Office 365 prior to making the changes on-premise.

 

It is common for the on-premise domain to have a .local extension. In these cases, it is required to add an alternate UPN suffix to the .local domain which matches the email addresses of the users begin migrated. For example, if the local domain is contoso.local, but the email domain is contoso.com (i.e. users have email addresses of joe@contoso.com) an alternate UPN suffix is required on the local domain. In addition, the user’s primary UPN needs to be modified to reflect the UPN which needs to match the email domain.

 

IdFix Tool

 

Microsoft provides a tool to make this process easier, it is called the IdFix tool. In fact, Microsoft does not recommend making the above changes without the tool. IdFix can find errors, report on errors, and even allow to take actions to edit or remove the attributes. All prior to attempting synchronization.

 

Conclusion

These are the main values in Active Directory which need to be validated or modified to ensure a smooth transition to Office 365, and IdFix can assist in identifying these values.