Skip navigation

Geek Speak

7 Posts authored by: exchangegoddess

Updating your Active Directory Schema is something that needs to be done from time to time whether we like it or not. It is done to either support a new version of the OS Domain controller or because an AD integrated application such as Exchange, Skype for Business or SCCM requires the update. Regardless of the reasons the mere mention of an Active Directory ( AD) Schema update would make administrators cringe. The dreaded fear of the schema update is mostly due to the fact that this an update that cannot be undone. There is no uninstall button that allows you to reverse your changes. Things would get complicated if you have AD-integrated applications or have third party applications that also extended your schema.

 

Active Directory is like a beating heart

 

For those not sure what Active Directory is, it is a database of objects that represents users, computers, groups etc in your network, as well as being used for authentication and authorization. The schema is the component of Active Directory that defines all the objects with classes and attributes. For each version of Windows Server Domain Services, for instance the schema is different between AD 2003 and AD 2008 and AD 20012. When you introduce a new Domain controller with newer version OS you will need to update your schema.

 

 

I sometimes refer to AD as the heart of the network. The flow of the network, your enterprise objects, pass through this beating heart and if it has a brief hiccup or is slowed down it can affect the overall function of your network. Users not being able to login to their computers can have major impacts to the business and productivity loss can cost lost dollars. A non-working heart can be almost paralyzing for some businesses.

 

Upgrade all things NOW!

 

If there is mention of a schema update most would tend to delay an upgrade until they felt it was “safe”. Now this push of new product releases every 18 -24 months by Microsoft, it has introduced a re-thinking of sorts. In effort to reduce the fear and increase upgrades they have made these schema updates a little less painful and sometimes almost transparent. With each new release they simplify and make it easier to deploy and update.

 

With Windows server 2012 they made that process simpler by simplifying the upgrade process. The functions of with adprep and /forestprep, /domainprep have now been wrapped up into the Active Directory Domain Services role installation process making the process much easier through a few click of next. You can still use the command and do it manually if you want to be old school.

 

 

Schema updates are almost required for every Exchange Service Pack or major CU update now. The same can be said for other Microsoft applications such as Skype for Business and SCCM. They have made it so easy that in some cases, by installing the Application update such as a CU for Exchange 2013 the schema update process was built into the application. Given that the account you were using to run the Exchange update had all the appropriate permissions to update AD the schema, the update would be easy and seamless.


I think the level of fear of schema updates has decreased somewhat in past several years with administrators having to do it more often and the process to update keeps getting easier by Microsoft. Now if you have third party applications that extend your schema that may not be as pain free. As with any upgrade/update, you should always plan accordingly and test as much as possible, even the simple point and click ones.

The “cloud” can mean so many things to different people. Depending on who you ask, it could mean SaaS ( software as a service ) running Salesforce in the cloud but another person may say it's running servers on AWS. The definition of cloud can be cloudy but the transition to cloud is the same regardless of what your putting there.

 

When you make that decision to transition the cloud, having a plan or tool kit is useful.  It’s very similar to an upgrade or deployment plan that I recently blogged about last month on Geek Speak called BACK TO BASICS TO HAVE A SUCCESSFUL UPGRADE. The same concept of project planning can be applied to transitioning to the cloud, with some minor tweaks and details to add.

 

Building you own “Cloud” Avengers…

 

If you want a smooth transition, it’s always best to get all the players involved from the start. Yes, that means networking, server team, application team and Security. I would say getting security involved from the start is key because they can shoot down plans because of not meeting some compliance standard, which then delays your transition. However, with security involved from the start means that you’re planning the right way from the start and will have a less likely chance of security delaying your project.  Getting everyone together, including the business (if applicable), gives everyone a chance to air out their grievances about the cloud and work together to make it a success.

 

“Cloud” Avengers assemble…

 

Now that you have your basic “Cloud” avengers core team built there are some common things that you should really ask with every cloud plan.

 

Disaster Recovery -  What is the DR plan for my cloud? If it is an application that is being moved to cloud, what are the DR plans for this application. Does the provider have DR plans for when their datacenter or servers decided to take a break and stop working? Are their DR plans for internet outages or DNS outages?


Backups - You should also be asking what are my back up options what is my recovery time if I need a restore. Lawsuits are common so how would an E-discovery situation be handled would be a question to ask. Where are the backups retained and for how long? How do you request data to be restored? Do the backup policies meet your in house policies?

 

Data retention – Something overlooked is data retention. How long does it stay in the cloud?  Each industry and business is different with different data retention periods so you will need to see if they meet your requirements. If there are deferring data retention periods, how does it impact your polices in house? Sometimes this may involve working your legal and compliance teams to come up with the best solution. E-discovery could also impact data retention periods so best to talk to the legal and compliance teams to make sure you are safe.

 

Data security - We all want to make sure our data secure so this should a standard question to ask. How is remote access handled and how easy can someone request access to the data. Is it as simple as sending an email or filling out the form? Does the provider have other means of authenticating that the correct person is requesting the data access? If you are running servers in the cloud you will want to know how the datacenters are secured. You will also want to know how the data is protected from antivirus if you are using SaaS and what are the remediation plans if data is compromised.

Back -out Plan -  If you are planning to transition to the cloud you should also have a back out plan. Sometimes you may find out it’s not all rainbows and sunny skies in the cloud and decide to come back to land. Asking the provider what are your options for backing out of the cloud is a good question to ask upfront because depending on your options this could impact your plan. You should also find out if there additional costs or fees for backing out. Something else that should also be asked is what happens if I want to leave the cloud and come back on premise what happens to my data and backups (if any existed). How has the data and can you get that back or does it get swallowed up by the cloud?

 

The cloud is the way of the future. As we move more and more data to the cloud, it may become less foggy. Until then plan as much as you can and ask all the questions you can ( even the stupid ones).

Love or hate it, Office 365 is here to stay. For most companies that have not made the transition to the Office 365 yet, I say yet because it is a matter of time before the majority of business are running email in the cloud. When you are planning to move email to the cloud there are many considerations to make and one of them is your network.

 

Your network is key when you want to live in the cloud. One of the first things you should do after you’ve made decision to go to the cloud is review your network and estimate how much bandwidth you will use. Office 365 adds increased usage because of the synchronization outlook and downloading of templates. The amount of users connecting to the cloud and type of tasks they do will impact your bandwidth. Network performance is impacted by what the users are doing, for instance if everyone is streaming video or having multiple video conference calls on your network that will certainly cause high bandwidth which can impact your connectivity to cloud services.

 

Migrating to Office is not an overnight task as some may think. It can take week to months to be completely migrated to the cloud and a lot of this depends on your network. It is highly recommended to test and validate your internet bandwidth as this will impact your migration. Mailbox sizes will impact how fast or slow the migration to the cloud will be. Let’s say your organization has about 100TB emails in your on-premise environment and you want to migrate all that to the cloud. I will tell you it will not help happen in days it will be more like months. Keep in mind Microsoft does throttle how much date you pump into their network each night. Let’s just say you are using an internet connection of 100Mbit/s and you are at 100% speed you are looking at least 8-9 months but given that there is throttling involved and possibly other outside factors that would also effect the speed and bandwidth your real estimate would likely be closer to 10-12 months.

 

Slow internet means slow migration and possible failures along the way.  If your still have slow MPLS sites these are not ideal for Office 365, however Microsoft has partner with a select few providers to use the ExpressRoute. ExpressRoute is a private connectivity to Microsoft Office 365.  Microsoft has some tools that you can use to help estimate your network requirements. One of the important ones to look at is the Exchange Client Network Bandwidth Calculator which estimates the bandwidth required for Outlook, Outlook Web App, and mobile devices.

 

Once you have made it to the cloud it does not stop there. Ongoing performance tuning maybe needed to ensure that your users are happy and do not experience email “slowness”.  Given that Microsoft has published best practices articles on slow networks for Office 365 I am pretty sure your network guys will be called a lot to check network performance. They do give some recommendations such as:

 

  • Upgrade to Outlook 2013 SP1 or later for substantial performance improvements over previous versions.
  • Outlook Web App lets you create offline messages, contacts, and calendar events that are uploaded when OWA is next able to connect to Office 365.
  • Outlook also offers an offline mode. To use this, you must first set up cached mode so that information from your account is copied down to your computer. In offline mode, Outlook will try to connect using the send and receive settings, or when you manually set it to work online.
  • If you have a smart phone, you can use it to triage your email and calendar over your phone carrier's network. ( yes this as a real alternative…)

 

At the end of the day it comes to making sure your network is up to snuff when you are making your way to the cloud or you may have some headaches. Good Luck

Now that Microsoft Windows server 2016 is generally available as of October 12, 2016, everyone is ready to upgrade their servers right? With every new Operating system release there is obviously going to be a list of new features and improvements. However, are these worth it to be bleeding edge and upgrade before the next service pack? Let’s take a quick look.

 

New and Improved

What’s new and probably a hot item is the support of containers. No, not your mom’s Tupperware but containers like Docker. With support for Docker Microsoft is playing nice with Open source which it would normally considers its competitor. This will help the big giant if they want to be a key player in the public cloud space and compete with the Amazon and Google. If you want to know how to get started with Docker on Windows Server 2016 check out Melissa Palmer’s post http://24x7itconnection.com/2016/10/11/getting-started-docker-container-platform-windows-2016/ .

Nano Sever is another hot item. It’s the headless server that is slimmer, faster and better than the tradition windows server. Think of it like server core mode but a lot better. You can install Nano from the Datacenter or Standard edition of windows 2016. It’s ideal for running as a compute host Hyper-V virtual machines.

Windows Server 2016 also introduces Host Guardian and shield vms. This “shields’ virtual machines and protects the data on them from unauthorized access. You can even lock out your Hyper-V admin. There are also improvements for Active directory certificate services, Active directory domain services, Active directory federation services, and Web application proxy to name a few. 

 

Are you Bleeding edge?

The new features sound great don’t they? But are you really going to jump on it right away? One could say I’m not using Windows server for containers or a Hyper-V host so I should be ok. However, if you're on the bleeding edge and want to start updating your servers you should know that they are a few things that have removed from server 2016.

The share and storage management not been in the MMC is no longer available in Windows Server 2016. So if you're thinking about managing servers with an older OS through Windows Server 2016 you won't be able too. You will need to logon locally to that older server use the snap in locally from that server.

Another change is the security configuration wizard has also been removed. This has been replaced by turning on all features by default. If you to manage those features, you can only do it through policy or the Microsoft security compliance manager tool.

 

Since this has only been generally available for about a month all the bugs and gotchas are starting to come out. Last week it was announced that there issues with running Exchange 2016 Cu3 on Windows Server 2016. If you're thinking about running Exchange 2016 on the latest version well you shouldn’t. There are known issues with the IIS host process and Microsoft says there's no workaround at this time so save yourself a headache and stick with windows server 2012.

 

So my advice is test, test, test and test before you go into production if you are going to upgrade to Windows Server 2016. It’s still very new out and over the new few weeks I am sure we will hear more rumblings of gotchas. 

As the 2016 year is coming to the end, I've looked back and wow it has been the year of the upgrades for me at my day job. While they have all been successful (some took longer than expected ) , there were bumps, tears and even some screaming to get to the finish line. My team and I are seasoned IT professionals but that didn't stop us from making mistakes and assumptions. What I've learned after doing 5 major upgrades this year is that never assume and always be prepared for the worst and hope for the best.

 

As you embark on the annual journey of upgrades there are so many factors to look at to make sure that it is successful. While it may seem trivia at times depending on the upgrade you do, it never hurts to go through a basic upgrade run through, like a playbook or if you have a PMO work with a Project Manager. Project Managers can be life savers! But you do not need a Project Manager if you take the time to go through and gather all the information and requirements as part of your planning.

 

After looking back through all the upgrades I've done this year,  I decided to write this post and hope that we can all learn a little something with the lessons we've learned and can be avoided by others.

Let’s get back to basics…

Once we start talking upgrades let's go back to the basics and answer the five “Ws” and get some requirements; WHAT, WHY, WHO, WHERE, and WHEN. Understanding those basic requirements goes a long way. It provides the basic foundation for understanding the situation and what all needs to be done.


WHAT- Let’s first ask what are we upgrading? Is this a server operating system upgrade or an application upgrade? Determining the type of upgrade is vital because this will affect the answers to your other requirements. Once you know what you are upgrading you will need to determine if your current environment can support the upgrade. Depending on what you are upgrading, it can feel like opening a can of worms, as you find you may need to upgrade other systems to make sure it’s compatible with the upgrade you are trying to complete. You may also find out that the upgrade reaches beyond your realm of responsible and crosses over into our departments and function. A “simple” application upgrade can end up costing millions if your current environment does not support all components.

 

Some examples questions to ask:

  1. If you're doing an application upgrade does your current hardware specs meet the recommendations for the newer version? If it does not, you may need to invest in new hardware.
  2. Is this an operating system upgrade?
  3. Is this an in-place upgrade or parallel environment?
  4. Or a complete server replacement?
  5. Can you go direct to the new version or will you need to install CU’s to get current?
  6. Can your current network infrastructure support the upgrade? Does it require more bandwidth?
  7. If you are using Load Balancers or Proxy Servers, do those support the upgrade?
  8. Are there client applications that connect to your systems and are you running supported versions of the client applications?
  9. Do you have Group Policies that need to be modified?
  10. What other applications “connect” maybe impacted?
  11. Are there any legacy customizations in the will be impacted?
  12. Will there licensing impacts or changes with the upgrade?

 

Sample upgrade scenario:

 

An application like Exchange Server has far reaching impacts beyond just the application. If an Exchange DAG is implemented the network must meet certain requirements to satisfy successful replication between the databases across datacenters. Working with your network team ensures your requirements are met. You will may possibly need the storage team if you are using a SAN for your storage which may require new hardware and we all know that can be a project in itself to upgrade a SAN.

 

An often overlooked item is the client connection to exchange. What version of Outlook are users using to connect to get to their email? If you are using an unsupported version of outlook users may have issues connecting to email. Which we all know would be a nightmare to deal with. Let’s look at the impact of outlook versions to an exchange upgrade. If your outlook versions are not supported, you will need to work with the desktop teams to get everyone to a supported version.  This can be costly, from the support to implementing and deploying the upgrade to supported outlook versions and then depending on how your Microsoft Office is licensed you may need to buy additional licenses and we all know that isn’t cheap. 

 

WHY - Let’s ask why are you doing the upgrade? Is the upgrade needed to address an issue or this to say current? Once this has been identified, you can find out what and or if new features you are going to be getting and what value does it bring to the table.

 

Additional questions to ask:

 

  1. Will any new features impact my current environment?
  2. If I am addressing an issue with the upgrade, what is it fixing and are there other workarounds?
  3. Will the upgrade break any customizations that maybe in the environment?
  4. Can the upgrade be deferred?

 

WHO- Once you’ve figured out the “WHAT” you will know the “WHO” that need to be involved. Getting all the key players will help make sure that you have your ducks in a row.

 

  1.     What other teams will you need to have involved?

 

      • Network team
      • Security Team
      • Storage Team
      • Database Team
      • Server Team
      • Application Team
      • Desktop Support
      • Help Desk
      • Project Management Team
      • Testing and certification Team
      • Communications team to inform end users
      • Any other key players – external business partners if your systems are integrated

 

In certain cases, you may need even need a technology partner to help you do the upgrade. This can get complicated as you will need to determine who is responsible for each part of the upgrade. Having a partner do the upgrade is convenient as they can assume the overall responsibility of the success of the upgrade and you can watch and learn from them. Partners can bring value as they are often “experts” and have done these upgrades before and should know the pitfalls and what to watch out for. If you are using a partner, I would recommend you do your own research in addition to the guidance and support provided by the partner because sometimes the ball can be dropped on their end as well. Keep in mind they are humans and may not know all about a particular application, especially it’s very new.

 

WHEN- When are you planning to do the upgrade? Most enterprises do not like disruptions so you will need to determine if this must be done on the weekends or can you do the upgrade without impacting users in production during the weekday.

 

The timing of your upgrade can impact other activities that maybe going on in your network. For example, you probably do not want to be doing an application upgrade like Skype for Business or Exchange the same weekend the Network team is replacing/upgrading the network switches. This could have you barking up trees when there isn’t really need to be.

 


WHERE– This may seem like an easy question to answer but depending on what your upgrading you may need to make certain arrangements. Let’s say your replacing hardware in the datacenter, you will certainly need someone in the datacenter to be able to perform the switch out. If your datacenter is hosted, perhaps you will need hands on tech to perform a reboot of the physical servers in the event the remote reboot doesn’t work.

 

I’ve been in situations where the reboot button doesn’t work and the power cord of the server had to be pulled to reboot the server back online, this involved getting someone on in the datacenter to do that. Depending on your setup and processes this may require you to put support tickets in advance and coordination with the hosting datacenter hosting team. Who wants to sit waiting around for several hours to have a server rebooted just to progress to the next step in an upgrade?

 

 

HOW - How isn't really a W but it is an important step. Sometimes the HOW can be answered by the WHAT, but sometimes it can't so you must ask "HOW will this get upgraded?". Documenting the exact steps to complete the upgrade, whether it's in place or parallel environment will help you identify any potential issues or key steps that maybe missing from the plan. Once you have the steps outline in detail it's good to do a walk through of the plan with all involved parties so all the expectations are clear and set. This is also helps prevent any scope creep that could appear along the way. Having a documented detailed step plan will also help during the actual upgrade in event something goes wrong and you need to do troubleshooting.

 

Proper Planning keeps the headaches at bay…

 

It would seem common sense and almost a standard to answer the 5 W’s when doing upgrades but you would be surprised but how often how many questions are not asked. Too often we get comfortable in our roles and overlook the simple things and make assumptions. Assumptions can lead to tears and headaches if they cause a snag in your upgrade. However, lots of ibuprofen can be avoided if we plan as best as can and go back to the basics of asking the 6 W’s for information gathering.

Emails is the center of life for almost every business in this world. When email is down businesses cannot communicate. There is loss of productivity which could lead to dollars lost, which in the end is not good.

Daily monitoring of Exchange involves many aspects of the environment and the surrounding infrastructure.  Simply turning on monitoring will not get you very far. First question you should ask yourself is “What do I need to monitor?” Not knowing what to look out for could inundate you with alerts which is not going to be helpful for you.

One of the first places to look at when troubleshooting mail slowness or other email issues is the network. Therefore, it is a good idea to monitor some basic network counters on the Exchange Servers. These counters will help guide you to determine where the root cause of the issue is.

 

Network Counters

The following tables displays acceptable thresholds and information about common network counters.

 

Counter

Description

Threshold

Network Interface(*)\Packets Outbound Errors

Indicates the number of outbound packets that couldn't be transmitted because of errors.

Should be 0 at all times.

TCPv6\Connection Failures

Shows the number of TCP connections for which the current state is either ESTABLISHED or CLOSE-WAIT. The number of TCP connections that can be established is constrained by the size of the nonpaged pool. When the nonpaged pool is depleted, no new connections can be established.

Not applicable

TCPv4\Connections Reset

Shows the number of times TCP connections have made a direct transition to the CLOSED state from either the ESTABLISHED state or the CLOSE-WAIT state.

An increasing number of resets or a consistently increasing rate of resets can indicate a bandwidth shortage.

TCPv6\Connections Reset

Shows the number of times TCP connections have made a direct transition to the CLOSED state from either the ESTABLISHED state or the CLOSE-WAIT state.

An increasing number of resets or a consistently increasing rate of resets can indicate a bandwidth shortage.

 

 


Monitoring Beyond the Exchange Environment


When your monitoring exchange not only are you monitoring for performance but you also want to monitor outside factors such as network, active directory, and any external connections such as mobile device management. All these external factors will affect the health of your Exchange environment.

In order to run Exchange, you need a network, yes routers and switches can impact exchange. As the exchange admin you don’t need to be aware of every single network event but a simple alert of a network outage or blip can be helpful. Sometimes all it takes is a slight blip in the network and it could have could affect your Exchange DAG by causing databases to fail over.

If you are not responsible for the network, then I would suggest you coordinate with your network team on what notifications you should be made aware in terms of network outages. Some key items to be informed or notified of are:

  • Planned outages between datacenters
  • Planned outages for network equipment
  • Network equipment upgrades and or changes that would affect the subnet your exchange servers reside on
  • Unplanned outages of network equipment and between datacenters
  • If your servers are virtualized, you should be informed of any host changes and/or virtual switch changes
  • Planned or unplanned DNS server changes because DNS issues can be a real nightmare

Preventing Bigger Headaches

Exchange Monitoring is a headache and can be time consuming but if you know what you are looking for and have the right tools in hand it is not so bad.  If the Exchange DAG is properly designed a network blip or outage should not take down your email for you company, this is the whole point of having an Exchange DAG( high availability design). What you may get is a help desk calls when users see that their outlook has disconnected briefly. Being informed of potential network outages can help you prepare in advance if you need to manually switch active copies of databases or when you need to do mailbox migrations. A network that is congested or having outages can cause mailbox migrations to fail, cause outlook clients to disconnect and even impact the speed of email delivery. Knowing ahead of time allows you to be prepared and have less headaches.

 


Email has become the core of every organization. It is the primary source for communication that everybody turns to, regardless of the type of email server they are running. Who doesn’t have email??? When email is down, communication is down, resulting in lost productivity and potentially thousands to millions of lost dollars.

 

Microsoft Exchange Server is the most widely used on-premises enterprise email system today. When it works…it works great. But, when Exchange is not working correctly, it can be a nightmare to deal with.

 

For an Exchange administrator, dealing with Exchange issues can be challenging because there are so many variables when it comes to email. Having a user complain about email being “slow” can be the result of many different factors. It could be a network issue, a desktop client issue, or even a poorly performing Exchange Server. So many possibilities of what is wrong and 1 unhappy user. 

 

Not only do issues arise in everyday working situations, but if you are preparing for a migration or an Exchange upgrade there are always “gotchas.” These are things that get overlooked until something breaks and then everybody is scrambling around to fix it and do damage control later. These are probably the most annoying to me because often times somebody else has run into the problem first. So, if I had known about the gotchas I could’ve been prepared.

 

I recently had the opportunity to present a webinar, “The Top Troubleshooting Issues Exchange Admins Face and How to Tackle Them.One of the great things about the IT community is that it’s there for us to share our knowledge, so others can learn from our experiences. That’s what I hoped to share in this webinarsome tips on solving annoying problems, as well as providing some true tried lessons from managing Exchange myself. We discussed some of the challenges with Exchange migrations, mailbox management issues (client issues), and even discussed Office 365. You can view a recording of the Webinar here.

 

Since our time was limited, I could not answer all the questions that were asked during the webinar, so I wanted to take an opportunity to answer some of them here:

 

1. Is there a size limit on outlook 2010/exchange 2010? We had a laptop user with a 20GB mailbox with cache mode enabled who had an issue with his offline address book dying within a day of his cache being resynced - we saw it as an issue with him trying to view other users calendars.

 

This type of issue can be many things and could be a whole blog in itself so I will keep it short. Large mailboxes will create large OST files locally on the machine they are using and can become corrupt. If that is the case, then creating a new OST file may resolve your issue. When trying to view others calendars, you can try removing the calendar and re-adding the shared calendar again. Also double check calendar permissions!

 

2. Do you know the issue when installing EX2010 SP3 it fails at 'removing exchange files'? SP3 is needed for upgrading to EX2013.

 

There is a known issue for Exchange failing to remove setup files with SP3 when PowerShell script execution is defined in Group Policy. For more details on this issue use the Microsoft KB# 2810617 site.


3. Any other resources we should review for Exchange Best Practices &/or Monitoring Tips (Other than Thwack?)

 

The Microsoft TechNet site has Exchange Best Practices, as well as Monitoring tips that be helpful. There are also various Microsoft MVP sites that can be helpful as well, such as:

 

http://exchangeserverpro.com/

http://www.stevieg.org/

http://www.expta.com/

 

 

4. Any advice for having Exchange 2003 and Exchange 2010 coexist until migration is completed?

 

Coexistence periods can be a challenge to manage and is best if kept to a short period if possible. Microsoft provides some checklist and documentation that can help with coexistence which can be found here on their TechNet site.

 

5. Is it possible to add more than 10 shared mailboxes to outlook 2010 client?

 

Yes, it is possible to have more than 10 shared mailboxes. By default, Outlook 2010 & Outlook 2013 has a default limit of 10 mailboxes with a maximum supported of up to 9999 accounts. To configure outlook for more than the default limits, you will need to edit registry settings or apply a Group Policy.

 

6. Is there a way can we enable "On behalf of" for the shared mailbox, so the end user who receives the email knows who sends the email?

 

To enable send on behalf for a shared mailbox, you can configure delegates for the shared mailbox. You can also apply the send on behalf of setting under the mail flow settings in the mailbox account properties.

 

 

I had a great time participating in the webinar with Leon and hope our viewers were able to take some tips back with them to help within their Exchange environment. Exchange is the core of most businesses and Managing an Exchange environment can be challenging, I know that from personal experience. However, given the right tools by your side you can tame the beast and keep the nightmare events to a minimum.

 

Filter Blog

By date: By tag: