Deploying SharePoint Solution Files to Non-12 Hive Locations on Multiple Web Front Ends

In a previous post, I mentioned having an issue deploying SharePoint solution files to a non-12 Hive locations on all web front ends (WFEs).  The problem I faced was that WSPBuilder doesn’t allow me to edit the manifest.xml file (reference, near bottom) and my custom code to copy the files was successful, but only executing on the WFE from which the feature activation command was being called.  Once we moved to a multiple WFE environment all of the other WFEs were missing files.

The always helpful Sean McDonough suggested that I use an SharePoint Timer job because that will execute code on all WFEs.  I had never built a custom timer job so I researched the links Sean shared and dove head first into it.  I had moderate success but ran into an issue with the account running my timer job (which ended up being the Farm Access account) not having write permissions to the non-12 Hive location as it was not a local admin on every WFE in the farm.  The solution to that problem (another blog post forthcoming on solving that ACL permission issue) was looping through the WFEs during feature activation.  As it turns out, discovering that I could loop through each WFE led to a much simpler solution to my original problem.2007-02-13-Ockhams_Razor    Any of you familiar with Occam’s Razor (also spelled Ockham) will realize that simpler solutions are almost always the better solution.  So instead of wiring up a feature to set write permissions, then store needed values in a property bag, and then kick off a timer job I went with a much simpler solution.  Below is a code snippet for how to deploy SharePoint solution files to a non-12 Hive location on multiple web front ends without using a timer job (wow that’s a mouthful.)

The files I am deploying are a set of support files for the RadEditor for MOSS Lite Edition that need to live in the “wpresources” folder (which is a sibling folder of the 12-Hive.)  I originally deploy the files to a subfolder “Support Files” of the feature root folder.  From there they are copied to the appropriate location within “wpresources”.  You may also download the code snippet from my SkyDrive here.

public override void FeatureActivated(SPFeatureReceiverProperties properties)

{

    // set source and destination folders

    string sourceFolder = properties.Definition.RootDirectory + @"Support Files";

    string destinationFolder = properties.Definition.RootDirectory + @"........wpresourcesRadEditorSharePoint4.5.6.0__1f131a624888eeedRadControlsEditor";

    List<string> filesToDeploy = new List<string>();


    // dynamically find all files in the source folder

    DirectoryInfo folder = new DirectoryInfo(sourceFolder);

    FileInfo[] filesInFolder = folder.GetFiles();

    foreach (FileInfo file in filesInFolder)

    {

        filesToDeploy.Add(file.Name);

    }


    // recurse through each web front end

    foreach (SPServer server in properties.Definition.Farm.Servers)

    {

        if (server.Role == SPServerRole.WebFrontEnd)

        {

            // copy support files per web front end

            foreach (string filename in filesToDeploy)

            {

                try

                {

                    // reference files based on network share format (serverNameC$...)

                    string sourceFile = @"" + server.Address + @"" + sourceFolder.Replace(":", "$") + @"" + filename;

                    string destinationFile = @"" + server.Address + @"" + destinationFolder.Replace(":", "$") + @"" + filename;


                    System.IO.File.Copy(sourceFile, destinationFile, true);

                }

                catch (Exception ex)

                {

                    // ..exception handling goes here

                }

            }

        }

    }

}

As far as I can tell my research didn’t turn up any other results on this topic so this may be me blazing some trails on the subject matter.  If you have any questions, comments, or feedback please feel free to leave some below.  I’ll update this post with a link to my forthcoming post on setting ACL permissions during feature activate.  Happy SharePointing.

-Frog Out

8 thoughts on “Deploying SharePoint Solution Files to Non-12 Hive Locations on Multiple Web Front Ends

  1. Originally posted on: https://briantjackett.com/archive/2009/12/30/deploying-sharepoint-solution-files-to-non-12-hive-locations-on-multiple.aspx#500579Brian,Nice job! When I mentioned that I was “curious” the other day, I was wondering if you might go the file copy route with SPServer (since it’s one of the few types that actually maps to something “physical” in the farm).This looks like a very straightforward approach, and as an added bonus, it looks like one that should be relatively easy to troubleshoot (from a code perspective) if problems do arise — no wrangling with SharePoint beyond the fact that this happens in a FeatureReceiver.A couple of watch-outs (or rather, points of awareness) for readers; the chances of these being actual issues are generally pretty small in all but the most security conscious of environments:1. Admin shares are employed during copy. Some administrators restrict or lockdown server admin shares, so if problems are encountered during the copy operations, one of those uncomfortable “admin-developer dialogs” might ensue. :-)2. Obviously, file-sharing being open between the activation box (typically the Central Admin host) and each WFE is assumed. In locked-down environments, SMB traffic (typically locked down to TCP and UDP port 445 for non-NBT file sharing) needs to be permitted between servers — not blocked by firewalls, IPSec rules, etc.Again, great solution, Brian. I’ll definitely be adding this approach to my arsenal. Thanks for sharing!

    Like

  2. Originally posted on: https://briantjackett.com/archive/2009/12/30/deploying-sharepoint-solution-files-to-non-12-hive-locations-on-multiple.aspx#500581Matthijs, When adding a WFE to the farm, SharePoint automatically adds all solutions and activates all features that are already deployed to the rest of the farm (one of my favorite advantages of SharePoint solutions.) I believe it performs a local add and deploy to the new server, but don’t quote me on that. My initial testing shows that the files (as in the above case) are properly deployed to the target location.

    Like

  3. Originally posted on: https://briantjackett.com/archive/2009/12/30/deploying-sharepoint-solution-files-to-non-12-hive-locations-on-multiple.aspx#500582Sean, Thanks for the feedback. You are correct that I am assuming the network shares and appropriate permissions are already in place. There is a very limited chance that security settings in your environment would be blocking access, but hopefully through debugging and exception handling that would be discovered quickly. On a related note, I was able to use your SPTimer job suggestion to solve a different problem on my current project. Thanks for pointing me in that direction.

    Like

  4. Originally posted on: https://briantjackett.com/archive/2009/12/30/deploying-sharepoint-solution-files-to-non-12-hive-locations-on-multiple.aspx#502569Nisha,By the looks of your server name “Exch-smtp” I would guess that’s an Exchange/SMTP server. When you enter the foreach loop and iterate through the servers, you’ll get every server associated with the farm. This includes application, database, index, SMTP, web front end, and any other type of servers.The first line of my foreach loop filters that list to make sure we are only working with web front ends after that. Make sure that if statement is included. Also check that the server in question indeed shouldn’t be considered a web front end. It may be mistakenly hosting content when it shouldn’t. You can fix an issue like that by changing the settings in Services on Server within Central Administration.Hope this helps. Let me know if you have further questions.

    Like

Leave a comment