Wait! Before you use that sample...!!!

One of the biggest mistakes developers and admins make is to take code or a script and plug it right into production.  Any and all code from any source samples really needs to be looked at and checked to be sure it does what you expect, does not cause issues and does nothing malicious.  All samples from Microsoft are just that - i.e. samples. They are intended to educate and demonstrate.  They are just samples and are not supported.  When you use a sample from Microsoft you need to make it your own code - so, if it does not work or causes issues then you need to work with it as your code. So, its important that you do a full code review and understand the API calls being made and if you don't understand them then you really need to do some research to see what those calls do.  So, never assume a sample will just work, work properly and won't cause issues - you need to review it, make it your own, debug it and test it. 

Many samples have a things in them which help provide proof that the code is running and add things like logging.  In samples like those which run as service, transport agents, there may be logging added to demonstrate the script running, however in an actual production application you would really want a different type of logging.  Again, there are differences between production code and a sample you would find on the net or on a Microsoft site.

When you use sample code the code is essentially yours and when you call in for developer support help on it the Microsoft engineer it as such - i.e. your code.  Developer support cases need the customer to have a developer engaged on the customer side who has access to the code in question and is familiar with the code and its calls. 

One situation we encounter from time to time is when some very bad things when an admin or developer finds a script or code and thinks its OK to just run it without understanding it fully. They might have ready the description and warnings from wherever they got it and be able to get it to run, however they end creating a very bad situation.   Sometimes recovery is extremely painful and can require having to use backups.  In some cases special code will need to be written which will attempt to restore things back or at least mitigate the issue.

Also please understand the Microsoft support does not modify or create production code for customer's.  

Here are some related articles:

Microsoft Developer Support does not write or maintain customer production code.
https://blogs.msdn.com/b/webdav_101/archive/2011/09/29/microsoft-developer-support-does-not-write-or-maintain-customer-production-code.aspx

Best Practices - What is supported and not.
https://blogs.msdn.com/b/webdav_101/archive/2015/05/06/ews-best-practices-what-is-supported-and-not.aspx

About: Messaging APIs
https://blogs.msdn.com/b/webdav_101/archive/2015/08/07/about-messaging-apis.aspx 

What's covered by support?  General questions and answers.
https://blogs.msdn.com/b/webdav_101/archive/2008/09/03/what-s-covered-by-support-general-questions-and-answers.aspx

Comments

• Anonymous
  August 19, 2015
  One would think this is common sense.

• Anonymous
  August 19, 2015
  The comment has been removed