Got an idea?
Would you like to suggest a proactive item or tip for the PFE team to write about?Tell us!
The best ideas will get a special edition shirt!
Mr. Proactive and Miss T. Proactive are Premier Field Engineers. Mr. Proactive is constantly looking for proactive items that he can share with Microsoft customers. Miss T. Proactive is always looking for Tips and Tricks to share.Here is the first post that started it all.
On the Exchange Team Blog, the Exchange product team posted two updates regarding Exchange 2007 SP3 RU3.
Yesterday, they announced that the re-release was coming soon. Additional information about the status of the Exchange 2010 SP1 RU3 can be found there as well.
Today, they announced that it has been re-released and that a new KB article regarding the update is now available here. The direct link to the download is here.
Yesterday afternoon, on the Exchange Team Blog, the Exchange product team posted that we are seeing issues with database corruption after installing Exchange 2007 SP3 RU3.
In short, we are recommending all customers uninstall Exchange 2007 SP3 RU3 on all Mailbox and Transport Servers.
Steps for how to do this are included in the blog post.
You will need to search for the events mentioned in order to determine the actions that you should take.
Additionally, we apologize that this happened.
I get asked all of the time for some kind of checklist from Microsoft that you could run through for an Exchange Server 2010 deployment.
One of the best tips that I can give anyone as far as the deployment of Exchange 2010 is to use the Exchange Server Deployment Assistant.
Seen it already? Go see it again. It is a living tool that changes as Microsoft discovers new information from your feedback and other sources and it has probably changed since the last time you looked at it. Remember the Setup.hta file that you might have used in your Exchange 2003 deployment? This is better since it gets updated.
Why is this tool so important? Well, since the release of Exchange 2010, we have found that the same deployment mistakes are happening across multiple customers. Many of those deployment mistakes could have been avoided if the administrator had followed the directions in this tool.
One of the great features of this tool is the ability to download the checklist to PDF format so that you can compare it offline with your internal deployment guide and make changes if necessary.
A big area where we often see deployment issues is the whole CAS scenario:
Guess what? All of these questions are covered in the tool. In fact some of these are titles for different sections.
Almost every section has the “How do I…?”, followed by “How do I know if this worked?” How cool is that?
Want to know the order that you should install servers? Follow the checklist.
What are the post-installation tasks? Follow the checklist.
Would we be so bold as to say that we have covered every scenario? No. Sometimes, we run across a new one that isn’t addressed by the tool. In those cases we have a “Feedback” link at the top of the page that allows you to make a suggestion directly to the team that writes the tool. I have personally seen requests for changes that have made it into the tool. Got a suggestion? Go ahead and let Microsoft know.
All in all, if this tool finds one area in your deployment that you might have missed, it is well worth the effort to check it out.
Got a tip for Miss T. Proactive? Send it to missproactive at Microsoft dot com.
Third-party SMB client software including but not limited to NetApp filers, Samba v3.0.22, and Vintela/Quest Authentication Services (VAS\QAS) clients may have a dependency on a field that was removed. Client software with this dependency will abort SMB session setup attempts after the negotiate response is received from the server. This problem occurs because the QFE version of the security update has an unexpected interaction with an encapsulated hotfix that causes the negotiate hint to be dropped from the negotiate protocol response. This is an optional field per RFC 4178 and is not required for Windows clients to perform negotiation correctly; however third-party SMB clients may have a dependency on this field.
We have confirmed that customers using earlier versions of the Samba smbclient (version 3.0.11 and earlier) and VAS\QAS clients (prior to 22.214.171.124) may experience problems. Customers running older versions of NetApp filers may experience problems if those filers are acting as SMB clients. Customers running VAS\QAS clients on Unix file servers may also experience this issue.
Below you will see an example network trace of the situation that may occur:
UNIX server with VAS Client = 192.168.1.100
Windows 2003 Server w/ MS11-014 = 192.168.1.123
61603 > microsoft-ds [SYN] Seq=0
Win=16384 Len=0 MSS=1460
microsoft-ds > 61603 [SYN, ACK] Seq=0
Ack=1 Win=64240 Len=0 MSS=1460
61603 > microsoft-ds [ACK] Seq=1
Ack=1 Win=17520 Len=0
Negotiate Protocol Request
Negotiate Protocol Response
61603 > microsoft-ds [FIN, ACK] Seq=63
Ack=154 Win=17520 Len=0
microsoft-ds > 61603 [FIN, ACK] Seq=154
Ack=64 Win=64178 Len=0
61603 > microsoft-ds [ACK] Seq=64
Ack=155 Win=17520 Len=0
Many third-party vendors have removed this dependency in recent updates. Later versions of the software listed above have been used to work around the problem. As a workaround, customers should contact their software vendors to see if an updated version of their client software is available.
There is an issue with some previous Outlook cumulative updates that will cause some clients to fail Autodiscover lookups.
Essentially what is happening is that the Outlook client uses the user principal name (UPN) instead of the Primary SMTP address for the lookup. If the UPN and SMTP address are different, Autodiscover will fail.
For instance, let’s say my primary SMTP address was email@example.com and the account that I logged in with (my UPN) was firstname.lastname@example.org. When I start up Outlook with a new profile and it queried my Exchange 2007 or Exchange 2010 server Autodiscover service, it should automatically create my profile for me. But if you have installed the Outlook 2010 Cumulative Update released October 26, 2010 or the Outlook 2007 Cumulative Update released January 11, 2011 then this is probably not working as intended. This also includes any cumulative updates that may have been released after them up to the fixes below.
This is fixed in the most recent cumulative updates for Outlook 2007 and Outlook 2010.
For Outlook 2010:
The fix is in the most recent Outlook 2010 Cumulative Update (February Update):
From that KB:
“The automatic profile configuration process that uses the Autodiscover service does not complete successfully in Outlook 2010 after you apply the hotfix package that is described in KB article 2405793.
Note The automatic profile configuration process uses the user principal name (UPN) instead of the primary SMTP address. Specifically, this issue occurs when the UPN differs from the primary SMTP address.”
For Outlook 2007:
The fix is in the most recent Outlook 2007 Cumulative Update (February Update):
”Consider the following scenario:
In this scenario, the Autodiscover service fails.”
Hopefully that is helpful. If you have any further questions please ask your PFE or TAM.
Hi There! My name is Mr. (Scoop) Proactive, and I am one of the Community Leads for Premier Field Engineering (PFE). My partner in crime is Miss T. Proactive (no relation). Miss T. won't ever tell me her real first name. She says it is "Tips and Tricks", but I can never tell if she is serious.
We started this blog so that the PFE community can share their proactive items with you as well as share "Tips and Tricks" that we come across. As PFEs, we do this all of the time with our customers. We see this as a great way to get the word out about what PFEs do. Which brings me to the next item...
What is a PFE? Glad you asked. Premier Field Engineers have gone by many names in the past: Alliance (Engineers, Consultant, Support Professionals), RRE (Rapid Response Engineer), ROSS (Rapid Onsite Support), the list could go on and on. But now, we all fall under the PFE umbrella. As a PFE, generally we are either Dedicated Support Engineers (DSE) or Transactional Engineers.
PFEs are known proactive offerings and for the great relationship that we have with our customers. We know the customers' environments and history of issues. This means that when they give us a call with a reactive issue, they don't have to go in to great detail about their environment, and we can focus on the issue that they are seeing immediately. But it also means that when we hear other customers are running into an issue, we can proactively let our customer know, so we can get ahead of it before it becomes a bigger problem. Kind of cool, right?
Transactional PFEs do a lot of the above, but they also deal with a lot more customers, since they are not assigned a specific customer generally, but a region of customers. This allows them to build a lot of great relationships. And many times, as the customers' see the value of a dedicated resource; they may end up asking for a DSE. Also, most of the Risk Assessment Programs (RAPs like ExRAP, ADRAP, SQLRAP, etc.), Workshops, and other offerings in our Premier Proactive Services catalog are handled by the Transactional PFEs. They are a very busy group of experts.
PFE is a truly great place to work. In fact, we will also be sharing job opportunities with you on a daily basis. (I kid... Maybe monthly... I don't like reading about job offerings either, but we are always looking for great people to work at the greatest company in the greatest role!) Ok, enough about that.
Also, since we have a large number of offerings that we provide customers that you may not be aware of, we will occasionally share the details with you so that you can jump on them as soon as they are available.
Well, that is enough for now. Keep this blog in mind since I am sure you will be enjoying some of the posts that we will be sharing. Feel free to contact me anytime with any questions you may have by clicking on the "Email Blog Author" link at the right. Both Miss T. and I get those emails and try to respond when we can.