SharePoint Automation

When I meet with clients to do design sessions, I’m often asked why Microsoft made a certain SPS process this or that way. In particular, the team site creation process from within a SPS portal seems to be a popular one. Compounding this is my advice for planning ahead. During the design of SPS/WSS implementations, I often propose dedicating virtual servers for groups of collaborative sites. I also push clients to consider many top-level sites versus very deep site collections. All of this is to provide the opportunity for growth. Dedicating virtual servers makes backup and restore processes easier and increases the ability to deliver a different SLA for team sites versus the portal. Having many top-level sites opens the ability to control more of what goes in what content database. However, some of these recommendations for my clients make SPS harder to use. The “Create Site” process of the portal Site Directory now isn’t enough. I want my clients’ admins to be aware of what virtual server, under what managed path, and with what naming convention they should be using when creating a site. So recently, I put together an example that shows that my advice can actually make SPS easier to use with a little bit of custom dev up front.  

Read my article which contains audiences, a custom web part page built in VS.NET, custom site definitions, and a custom RowConsumer web part: https://blogs.msdn.com/edhild/articles/407610.aspx