Archive for April, 2012


Quest MessageStats: Own Your Exchange Environment

Filed Under: BPOS/Office 365, Exchange, Quest by Matt — Leave a comment
April 16, 2012

When I work with clients on Exchange upgrades/migrations, I go through a standard list of questions to get their current state environment.  These questions are important in terms of appropriately sizing a messaging environment, and very often the clients end up estimating numbers because they don’t have any empirical data to work with.  Enter Quest and their MessageStats software.

MessageStats aggregates Exchange data and provides easy to use reports at the click of a button.  A few of the reports available can be seen in the Report List image.  Many of the current state assessment questions can be easily answered with these stock reports.  Want to know average message size or how many messages are sent/received per day?  One click.  Want to know top senders and/or receivers?  I can provide a graph and specific details easily.

 

 

 

 

 

 

 

Above and beyond the stock reports is the ability to create my own meaningful reports for “at a glance” environment reporting and even provide some internal numbers to allow for financial assessments.  For a per-mailbox cost, this tool pays for itself in the amount of effort it saves (and how good it makes me look when management asks questions about Exchange).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I recommend this tool to every client I work with, and offer to set up the free 90-day demo environment to show them how it is effective and easy to use.  It can be used for Exchange 2007/2010 and/or Exchange Online (Office 365).  There are additional reporting packs not only for OWA, but also for OCS 2007/Lync 2010 and a variety of other Exchange-integrated applications.  Project Leadership Associates is a Quest partner and can assist with not only MessageStats deployments, but also any of their other tools used for managing a messaging solution.

http://www.quest.com/messagestats/

 

 

Comment

Office 365 Deployment Considerations

Filed Under: BPOS/Office 365, Exchange, Lync, Migration by Matt — Leave a comment
April 3, 2012

During my client interactions, a couple of recurring confusions continue to plague the decision making process to move to Office 365.  I wanted to take a moment to document them for other to get some fast answers.

1. Directory Synchronization is Required for Single Sign-On with Office 365.

The two main components of SSO with Office 365 are Directory Synchronization and Active Directory Federation Services 2.0 (ADFS 2.0).  They are both necessary for a client to log on to Office 365 using their current Active Directory credentials.  The key road block for some clients is that Directory Synchronization synchronizes the entire directory; all users, all groups.  Yes, there are ways around this; no, they are not supported by Microsoft.  Additionally, Directory Synchronization is limited to a single AD Forest at this time.  Future functionality may provide solutions to these two concerns, but they are facts that have to be communicated today.

2. Lync Federation is Not the Same as Active Directory Federation Services.

Lync Federation is  the ability to IM other companies that also use Lync Online or Lync on-premises, as well as see Presence and limited status information (depending on the configuration settings).  This is not SSO.

3. Exchange Federation is (also) Not the Same as Active Directory Federation Services.

Exchange Federation allows Exchange Online and Exchange 2010 environments to share Calendaring information, depending on configuration settings.  This is not the same as SSO.

3. Lync On-Premise and Lync Online Cannot Share the Same SIP Domain

At this time, Lync On-Premise and Lync Online cannot share the same SIP domain.  In order to have coexistence between the two within a single organization, two separate SIP domains and Lync Federation between those domains needs to be configured.  This will likely change in the future.

4. ADFS 1.0 is Not Used for Office 365

ADFS 1.0 is the version available in Windows Server 2008 within the Roles configuration settings.  This will not work for Office 365 federation configuration.  ADFS 2.0 is a separate download that will need to be installed.

Hopefully these points will help clear up any confusion during your planning process and allow you to focus on the other hurdles that come along with any migration effort.

What other deployment confusion have you seen in the field?  I’m always ready to learn from someone else’s hard work…

Tags: ,
Comment

Engaging Professional Support Channels

Filed Under: Migration by Matt — Leave a comment
April 2, 2012

For many technically adept people, professionally employed or otherwise, we often have an inclination to troubleshoot a problem independently of outside professional support channels as long as possible.  Sometimes we get tunnel vision, sometimes we don’t want to look bad in front of others, and sometimes we flat out just don’t want to deal with Level 1 tech support prior to getting the issue escalated (“Yes, I, too, read the documentation, did the same web search and read the same 2-year-old blogs!”)

However, with cloud services like Office 365, we are now in an environment where we don’t have all of the information available to us.  We can’t get all the logs and, most importantly, we don’t know what’s going on in the Microsoft environment at the time we’re having a problem.  Unpublished downtime, networking issues and server bugs are all issues that I have experienced in different client environments when configuring various elements of Office 365.  As a rule, I now submit a service ticket before any significant level of troubleshooting happens just to make sure I’ve put the gears in motion.  If I can resolve the problem quickly on my own, then I can close the ticket on my own.  Support is included with Office 365, so there is no financial risk here.  On the other hand, if I don’t have all the information needed to resolve the problem on my own (or the necessary permissions), then I’m already one step closer to either getting past Level 1 tech support…or having Level 1 tech support point out the one detail that I missed while thinking I couldnt’ possibly be the cause of the problem…  Either way, the issue gets resolved much faster than pouring over all the information we’ve seen time and time again.

For those not professionally managing these environments, this mentality should be kept in mind as a reason to engage a professional services team before starting on a deployment/migration project.  A Microsoft partner can bring project experience and expertise to the table that can help offset many frustrations, both from a technical and a business standpoint.  Why sit on the phone with support for hours at a time when we’ve already seen it before?  Also, by the time you’re neck deep in a failed migration, it’s much harder technically and time-wise for a consultant to simply “jump in and fix it”.  Projects go best when they’re done correctly from the start.  Raise your odds of success and have a Microsoft partner relationship established before starting your project.

Comment