http://sqlblog.com/search/SearchResults.aspx?o=DateDescending&tag=SQL+Server+2012,sql+server+integration+services,PBM&orTags=0Search results matching tags 'SQL Server 2012', 'sql server integration services', and 'PBM'en-USCommunityServer 2.1 SP2 (Build: 61129.1)http://sqlblog.com/blogs/jamie_thomson/archive/2012/02/09/pbm-for-ssis-what-policies-would-you-want-or-need.aspxThu, 09 Feb 2012 13:50:00 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:41649jamiet<p>My mind was wandering today after reading Andy Leonard's excellent post <a href="http://sqlblog.com/blogs/andy_leonard/archive/2012/02/09/ssis-snack-name-those-connections.aspx" target="_blank">Name Those Connections</a> and it occurred to me that due to SQL Server 2012 including an <a href="http://sqlblog.com/blogs/jamie_thomson/archive/2010/11/13/ssis-server-catalogs-environments-environment-variables-in-ssis-in-denali.aspx" target="_blank">SSIS Server</a> there may be an opportunity to leverage <a href="http://msdn.microsoft.com/en-us/library/bb510667.aspx" target="_blank">Policy-Based Management</a> (PBM) for ensuring adherance to an organisation's best practises around SSIS development. I have absolutely no idea whether such plans are afoot or not (I suspect not) but nonetheless it may be fun to come up with a desired list of policies. Here are some brainstormed ideas:</p><ul><li>All task and package names have to adhere to some naming convention (<a href="http://sqlblog.com/blogs/jamie_thomson/archive/2012/01/29/suggested-best-practises-and-naming-conventions.aspx" target="_blank">here are some suggestions</a>)</li><li>All executions need to use an environment reference</li><li>All Connection Managers must be project-scoped</li><li>All connection strings must use an Application Name that is not a GUID (this is where this train of thought started after reading Andy's post)</li><li>Insist on a given LOGGING_LEVEL<br></li></ul><p>Any more ideas? Pop 'em in the comments below!</p><p><a href="http://twitter.com/jamiet" target="_blank">@Jamiet</a> <br></p>