{"id":17121,"date":"2010-09-14T00:01:00","date_gmt":"2010-09-14T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2010\/09\/14\/use-powershell-to-script-changes-to-the-sharepoint-web-config-file\/"},"modified":"2010-09-14T00:01:00","modified_gmt":"2010-09-14T00:01:00","slug":"use-powershell-to-script-changes-to-the-sharepoint-web-config-file","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/use-powershell-to-script-changes-to-the-sharepoint-web-config-file\/","title":{"rendered":"Use PowerShell to Script Changes to the SharePoint Web.config File"},"content":{"rendered":"

 <\/p>\n

Summary<\/strong>: Learn how to use Windows PowerShell to script changes to the web.config<\/strong> file on SharePoint 2010.<\/p>\n

 <\/p>\n

\"Hey, Hey, Scripting Guy! I need help using Windows PowerShell to automate making changes to the web.config<\/strong> file on my SharePoint 2010 farm. Do you know of a way to automate making these changes?<\/p>\n

— JG<\/p>\n

 <\/p>\n

\"Hey, Hello JG, <\/p>\n

Microsoft Scripting Guy Ed Wilson here. We are continuing with Guest Blogger Week, and today’s guest blogger is Josh Gavant who will talk about SharePoint.<\/p>\n

Josh is a Premier Field Engineer (PFE) with Microsoft who specializes in both SharePoint and Windows PowerShell. Before joining Microsoft in fall 2009 he helped build and maintain an enterprise SharePoint farm for a United States government agency. Find SharePoint and Windows PowerShell-related discussions from Josh and contact him via his blog at http:\/\/blogs.msdn.com\/b\/besidethepoint<\/a>.<\/p>\n

Take it away, Josh. <\/p>\n

 <\/p>\n

What SharePoint Is and Is Not<\/h4>\n

When discussing SharePoint with customers, I often find myself emphasizing that a SharePoint farm is, in essence, a logical collection of services—not a collection of physical servers. When administrators and developers make modifications to their farm, they are manipulating and configuring these logical services; changes to files and other “physical” artifacts are a side effect of the logical changes. Another way of expressing this is to emphasize that changes to SharePoint should actually be perceived only as changes to the Object Model and ultimately the shared databases, not to any server-level constructs (for example, the file system or registry).<\/p>\n

To this end, SharePoint engineers constantly emphasize to developers the importance of using Solution (capital S) packages to deploy customizations to SharePoint. Solution packages upload all the files and other pieces necessary for new SharePoint artifacts to the SharePoint database, from where SharePoint itself handles deploying them to component servers as necessary.<\/p>\n

The Solution package is well and good for developers, but what about administrators who need to make farm-wide changes? For example, administrators sometimes need to modify the web.config<\/strong> files that govern the behavior of SharePoint Web Applications, or need to modify IIS settings, registry keys, or files on multiple SharePoint servers. Ideally, administrators would create single “solutions” to deal with configuring a single SharePoint logical service, instead of having to repeat processes on lots of physical servers. The SharePoint administrator tools are fine for single server installations, as shown in the following image. But such a procedure is difficult to maintain, hinders scale-out of a SharePoint farm, and is antithetical to the management paradigm espoused above, viewing SharePoint as a collection of logical services.<\/p>\n

\"Image<\/a><\/p>\n

So what is an administrator to do? Windows PowerShell scripts, the SharePoint Management Shell, and the SharePoint administrative object model provide a Solution<\/strong> solution (sic) for SharePoint farm administrators. In this post, we explore using these tools to write a single reusable script that modifies the web.config<\/strong> file for a Web Application across an entire farm. Though we’ll focus on a single example, the concepts can be utilized for any web.config<\/strong> modifications.<\/p>\n

Introducing Today’s Audience Participant, the SharePoint BlobCache<\/h4>\n

A commonly implemented configuration change for SharePoint Publishing sites is that of enabling the BlobCache<\/strong> for the parent Web Application. The BlobCache<\/strong> is a special file-system cache created on SharePoint front-end web servers to store binary large objects (BLOBs) such as images, text files, and media files retrieved from SharePoint content databases. By storing these files in the BlobCache<\/strong>, the front-end server saves a trip back to the content database when serving these files for subsequent requests, improving response times. In addition, when administrators configure and enable the BlobCache<\/strong>, they can cause SharePoint to add a HTTP cache header to the file as it is delivered to the browser, which instructs the browser to rely on its cached version of the file for some defined period. This helps speed up repeat requests for pages on the client side.<\/p>\n

With these benefits, it’s easy to see why administrators and managers would want to turn on the SharePoint BlobCache<\/strong>. Unfortunately, the documented way to do so involves manually changing the web.config<\/strong> file for every effected Web Application on every front-end Web server, a process that can be difficult to maintain and control without errors. What we need is a way to modify the web.config<\/strong> for a Web Application across the farm in a single stroke.<\/p>\n

SPWebConfigModification<\/h4>\n

Enter SPWebConfigModification<\/strong>. This object contains properties for making changes to web.config<\/strong> files for an associated Web Application. The job of the administrator or developer is to construct one of these objects and assign appropriate values to its properties, and then add the new object to the collection of modifications associated with a given Web Application. After this is done, SharePoint takes care of applying the modification to all instances of that Web Application across the farm, including any additional servers added in the future. Another benefit is that by removing the modification from the list, the change is automatically reverted, which returns every server to its default original state.<\/p>\n

Voila! With SPWebConfigModification<\/strong>, web.config<\/strong> changes no longer need to involve directly touching files or settings on any server.<\/p>\n

So how can you create and apply these changes via Windows PowerShell? There are three steps to follow: <\/p>\n

    \n
  1. Construct and configure the SPWebConfigModification<\/strong> object.<\/li>\n
  2. Get a SPWebApplication<\/strong> object to which to add your modifications.<\/li>\n
  3. Wrap your work in a function for reusability. <\/li>\n<\/ol>\n

    You’ll also implement a complementary function to potentially undo the changes that you make. Let’s get started.<\/p>\n

    Construct and Configure the SPWebConfigModification Object<\/h4>\n

    When Windows PowerShell and its loaded snap-ins do not contain a cmdlet for returning an object that you want to use, you often can use the New-Object<\/strong> cmdlet to create an instance of that object. New-Object<\/strong> takes the fully qualified name of a type and an array of objects as its two main parameters; the array of objects contains the arguments to be passed to the object’s constructor<\/strong> method.<\/p>\n

    In this case, you are going to call the default constructor for Microsoft.SharePoint.Administration.SPWebConfigModification<\/strong>, which takes no arguments, and then store your newly constructed object in a variable for further manipulation. Here is the line:<\/p>\n

    \n
    $configMod1<\/span> <\/span>=<\/span> <\/span>New-Object<\/span> <\/span>Microsoft.SharePoint.Administration.SPWebConfigModification<\/span> <\/div>\n<\/blockquote>\n

    Next, set the properties needed to change the enabled attribute for the BlobCache<\/strong> node in the web.config<\/strong> file:<\/p>\n

    \n
    $configMod1<\/span>.Path<\/span> <\/span>=<\/span> “configuration\/SharePoint\/BlobCache”
    <\/span>$configMod1<\/span>.Name<\/span> <\/span>=<\/span> “enabled”
    <\/span>$configMod1<\/span>.Value<\/span> <\/span>=<\/span> “true”
    <\/span>$configMod1<\/span>.Sequence<\/span> <\/span>=<\/span> <\/span>0<\/span>
    <\/span>$configMod1<\/span>.Owner<\/span> <\/span>=<\/span> “BlobCacheMod”
    <\/span>##<\/span> <\/span>SPWebConfigModificationType.EnsureChildNode<\/span> <\/span>-><\/span> <\/span>0<\/span>
    <\/span>##<\/span> <\/span>SPWebConfigModificationType.EnsureAttribute<\/span> <\/span>-><\/span> <\/span>1<\/span>
    <\/span>##<\/span> <\/span>SPWebConfigModificationType.EnsureSection<\/span> <\/span>-><\/span> <\/span>2<\/span>
    <\/span>$configMod1<\/span>.<\/span>Type<\/span> <\/span>=<\/span> <\/span>1<\/span> <\/div>\n<\/blockquote>\n

    The various properties can be tricky, and the required values change based on the SPWebConfigModificationType<\/strong> chosen for the Type<\/strong> property. In this case, you want to make sure that an attribute on an existing node takes on a specific value, so we choose EnsureAttribute<\/strong> as the value for the Type<\/strong> property. There are a few ways of choosing values from an Enum<\/strong> in Windows PowerShell; for this script, I am simply using the integer value that the specific Enum<\/strong> choice corresponds to, as noted in the comments for setting the Type<\/strong> property.<\/p>\n

    The Path<\/strong> property expects an XPath expression pointing to the element that we will be considering; Name<\/strong> refers to the attribute on that element to check. Sequence<\/strong> determines precedence if multiple SPWebConfigModification<\/strong> objects attempt to modify the same attribute; the lower the number, the higher the priority. By choosing 0<\/strong>, I’ve overridden any other change. Value<\/strong> determines the actual value that the attribute will be set to. The result of this modification will be setting enabled=”true”<\/strong> on the BlobCache<\/strong> node in web.config<\/strong>.<\/p>\n

    One last property is the Owner<\/strong> property. The value of this property is arbitrary, but it is useful in locating specific modifications for manipulation after they have already been added to a collection. As you will see, for our reversion function you can find the modifications by checking the value assigned to this property.<\/p>\n

    With these steps completed, you have the first of our two SPWebConfigModifications<\/strong>. The second one sets the Max-Age<\/strong> attribute on the same BlobCache<\/strong> node. This sets the Max-Age<\/strong> HTTP header on the outgoing file so that browsers know to cache the object for the specified period. This modification is seen in the following Windows PowerShell code:<\/p>\n

    \n
    $configMod2<\/span> <\/span>=<\/span> <\/span>New-Object<\/span> <\/span>Microsoft.SharePoint.Administration.SPWebConfigModification<\/span> <\/p>\n

    <\/span>$configMod2<\/span>.Path<\/span> <\/span>=<\/span> “configuration\/SharePoint\/BlobCache” <\/p>\n

    <\/span>$configMod2<\/span>.Name<\/span> <\/span>=<\/span> “max-age” <\/p>\n

    <\/span>$configMod2<\/span>.Value<\/span> <\/span>=<\/span> “86400” <\/p>\n

    <\/span>$configMod2<\/span>.Sequence<\/span> <\/span>=<\/span> <\/span>0<\/span> <\/p>\n

    <\/span>$configMod2<\/span>.Owner<\/span> <\/span>=<\/span> “BlobCacheMod” <\/p>\n

    <\/span>##<\/span> <\/span>SPWebConfigModificationType.EnsureChildNode<\/span> <\/span>-><\/span> <\/span>0<\/span> <\/p>\n

    <\/span>##<\/span> <\/span>SPWebConfigModificationType.EnsureAttribute<\/span> <\/span>-><\/span> <\/span>1<\/span> <\/p>\n

    <\/span>##<\/span> <\/span>SPWebConfigModificationType.EnsureSection<\/span> <\/span>-><\/span> <\/span>2<\/span> <\/p>\n

    <\/span>$configMod2<\/span>.<\/span>Type<\/span> <\/span>=<\/span> <\/span>1<\/span> <\/div>\n<\/blockquote>\n

    The setup and properties for this modification follow the same pattern as the previous one. Choose a value of 86400 seconds, or 24 hours, as a reasonable time for the browser to rely on its cached version of a file. Once again, set the Owner<\/strong> property to BlobCacheMod<\/strong> to help find this modification when you need to remove it.<\/p>\n

    Get a SPWebApplication Object with Which to Work<\/h4>\n

    You have created your SPWebConfigModification<\/strong> objects; now add them to the WebConfigModifications<\/strong> property of the Web Application they will be applied to. To do this, start by creating an instance of a SPWebApplication<\/strong> object. In the SharePoint 2007 days, I might have asked the user of the function to supply us with a URL, and then I would use the static SPWebApplication.Lookup()<\/strong> method to return an instance. While this tactic would still be valid in SharePoint 2010, there are now more robust options available.<\/p>\n

    Introducing SPCmdletPipeBind<TCmdletObject><\/h4>\n

    As with many other Microsoft-provided foundations in SharePoint, the SharePoint team has taken the Windows PowerShell framework and extended it specifically for SharePoint: the classes and utilities provided by the Microsoft.SharePoint.PowerShell<\/strong> namespace. This namespace contains not only the 500-plus SharePoint-specific cmdlets, but also a set of utility classes for creating more SharePoint cmdlets and scripts, in addition to allowing us to work more easily with the SharePoint object model.<\/p>\n

    In SharePoint 2010, instead of asking the user for a string or even an SPWebApplication<\/strong> object, you can specify a SPWebApplicationPipeBind<\/strong> object, itself derived from the generic SPCmdletPipeBind<TCmdletObject><\/strong> class. The idea behind the PipeBind<\/strong> classes is that they allow the same object to be referred to in different ways. In the case of SPWebApplication<\/strong>, you can pass a string representing the URL of the Web Application, a GUID identifying the specific SharePoint configuration object that is the Web Application, or even an actual SPWebApplication<\/strong> object (that is, output from the pipeline or stored in a variable). The SPWebApplicationPipeBind<\/strong> class takes care of ultimately returning a SPWebApplication<\/strong> object for further manipulation in the shell. An immediate benefit of using the PipeBind<\/strong> classes is you can accept SPWebApplication<\/strong> objects output by previous cmdlets in the pipeline without making it difficult to call the cmdlet in standalone fashion, passing it a URL as a string.<\/p>\n

    The function will expect a SPWebApplicationPipeBind<\/strong> object and will convert this object into a true SPWebApplication<\/strong> object for further manipulation. Here are the relevant lines in the script:<\/p>\n

    \n
    param(<\/span> <\/p>\n

        <\/span>[Parameter(Mandatory<\/span>=<\/span>$true<\/span>,<\/span> <\/span>ValueFromPipeline<\/span>=<\/span>$true<\/span>,<\/span> <\/span>Position<\/span>=<\/span>0<\/span>)]<\/span> <\/p>\n

        <\/span>[Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind]<\/span> <\/p>\n

        <\/span>$WebApplication<\/span> <\/p>\n

    <\/span>)<\/span> <\/p>\n

    <\/span>process<\/span> <\/span>{<\/span> <\/p>\n

        <\/span>$WebApp<\/span> <\/span>=<\/span> <\/span>$WebApplication<\/span>.Read()<\/span> <\/div>\n<\/blockquote>\n

    The Parameter<\/strong> attribute is typical for an advanced Windows PowerShell function, specifying that the parameter is mandatory, can be accepted directly from the pipeline, and does not have to be named. The second pair of square brackets ([ ]<\/strong>) specify the type of the parameter: a SPWebApplicationPipeBind<\/strong> object. Finally, the first action within the Process<\/strong> block of the cmdlet is to call the Read<\/strong> method on the PipeBind<\/strong> object that was received, which is the defined method for extracting the relevant TCmdletObject<\/strong> from the SPCmdletPipeBind<\/strong>-derived class.<\/p>\n

    What this all means at the end of the day is that the $WebApp<\/strong> variable now contains a SPWebApplication <\/strong>object to which you can add your web.conf<\/strong>ig modifications.<\/p>\n

    Add the Modifications to the SPWebApplication Object<\/h4>\n

    While the previous section might have been your first direct encounter of the PipeBind<\/strong> kind, this next part should be a bit simpler. The SPWebApplication<\/strong> instance you are now the proud parent of contains a property WebConfigModifications<\/strong> that references a Collection<\/strong> <SPWebConfigModification><\/strong> object; that is, a collection of SPWebConfigModifications<\/strong>. The Collection<\/strong> class offers a lot of useful functionality, but let’s focus only on its Add<\/strong> and Remove<\/strong> methods. To add the new SPWebConfigModification<\/strong> objects to the collection associated with a Web Application, use the following two lines:<\/p>\n

    \n
    $WebApp<\/span>.WebConfigModifications.Add(<\/span> <\/span>$configMod1<\/span> <\/span>)<\/span> <\/p>\n

    <\/span>$WebApp<\/span>.WebConfigModifications.Add(<\/span> <\/span>$configMod2<\/span> <\/span>)<\/span> <\/div>\n<\/blockquote>\n

    To ensure that the changes are persisted back to the SharePoint configuration object for the Web Application in the configuration database and thus propagated out to all instances of the Web Application in the farm, call Update()<\/strong>:<\/p>\n

    \n
    $WebApp<\/span>.Update()<\/span> <\/div>\n<\/blockquote>\n

    Finally, to apply these new modifications across the farm, you can call the appropriate method on the SPWebService<\/strong> object, the host service for all SPWeb<\/strong>Applications, which is also the parent of the Web Application in question:<\/p>\n

    \n
    $WebApp<\/span>.Parent.ApplyWebConfigModifications()<\/span> <\/div>\n<\/blockquote>\n

    And with that, the web.config<\/strong> files for this Web Application across our entire farm will be modified. If you want to verify these changes, call Get-SPWebApplication<\/strong> and check the value of the WebConfigModifications<\/strong> property for the Web Application that you modified.<\/p>\n

    Complete Function<\/h4>\n

    Here is the complete script for the previous work, all wrapped in a nice function.<\/p>\n

    \n
    function<\/span> <\/span>Enable-SPBlobCache<\/span> <\/span>{<\/span> <\/p>\n

    <\/span>param(<\/span> <\/p>\n

        <\/span>[Parameter(Mandatory<\/span>=<\/span>$true<\/span>,<\/span> <\/span>ValueFromPipeline<\/span>=<\/span>$true<\/span>,<\/span> <\/span>Position<\/span>=<\/span>0<\/span>)]<\/span> <\/p>\n

        <\/span>[Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind]<\/span> <\/p>\n

        <\/span>$WebApplication<\/span> <\/p>\n

    <\/span>)<\/span> <\/p>\n

    <\/span>process<\/span> <\/span>{<\/span> <\/p>\n

        <\/span>$WebApp<\/span> <\/span>=<\/span> <\/span>$WebApplication<\/span>.Read()<\/span> <\/p>\n

        <\/span>#<\/span> <\/span>SPWebConfigModification<\/span> <\/span>to<\/span> <\/span>enable<\/span> <\/span>BlobCache<\/span> <\/p>\n

        <\/span>$configMod1<\/span> <\/span>=<\/span> <\/span>New-Object<\/span> <\/span>Microsoft.SharePoint.Administration.SPWebConfigModification<\/span> <\/p>\n

        <\/span>$configMod1<\/span>.Path<\/span> <\/span>=<\/span> “configuration\/SharePoint\/BlobCache” <\/p>\n

        <\/span>$configMod1<\/span>.Name<\/span> <\/span>=<\/span> “enabled” <\/p>\n

        <\/span>$configMod1<\/span>.Sequence<\/span> <\/span>=<\/span> <\/span>0<\/span> <\/p>\n

        <\/span>$configMod1<\/span>.Owner<\/span> <\/span>=<\/span> “BlobCacheMod” <\/p>\n

        <\/span>##<\/span> <\/span>SPWebConfigModificationType.EnsureChildNode<\/span> <\/span>-><\/span> <\/span>0<\/span> <\/p>\n

        <\/span>##<\/span> <\/span>SPWebConfigModificationType.EnsureAttribute<\/span> <\/span>-><\/span> <\/span>1<\/span> <\/p>\n

        <\/span>##<\/span> <\/span>SPWebConfigModificationType.EnsureSection<\/span> <\/span>-><\/span> <\/span>2<\/span> <\/p>\n

        <\/span>$configMod1<\/span>.<\/span>Type<\/span> <\/span>=<\/span> <\/span>1<\/span> <\/p>\n

        <\/span>$configMod1<\/span>.Value<\/span> <\/span>=<\/span> “true” <\/p>\n

        <\/span>#<\/span> <\/span>SPWebConfigModification<\/span> <\/span>to<\/span> <\/span>enable<\/span> <\/span>client-side<\/span> <\/span>Blob<\/span> <\/span>caching<\/span> <\/span>(max-age)<\/span> <\/p>\n

        <\/span>$configMod2<\/span> <\/span>=<\/span> <\/span>New-Object<\/span> <\/span>Microsoft.SharePoint.Administration.SPWebConfigModification<\/span> <\/p>\n

        <\/span>$configMod2<\/span>.Path<\/span> <\/span>=<\/span> “configuration\/SharePoint\/BlobCache” <\/p>\n

        <\/span>$configMod2<\/span>.Name<\/span> <\/span>=<\/span> “max-age” <\/p>\n

        <\/span>$configMod2<\/span>.Sequence<\/span> <\/span>=<\/span> <\/span>0<\/span> <\/p>\n

        <\/span>$configMod2<\/span>.Owner<\/span> <\/span>=<\/span> “BlobCacheMod” <\/p>\n

        <\/span>##<\/span> <\/span>SPWebConfigModificationType.EnsureChildNode<\/span> <\/span>-><\/span> <\/span>0<\/span> <\/p>\n

        <\/span>##<\/span> <\/span>SPWebConfigModificationType.EnsureAttribute<\/span> <\/span>-><\/span> <\/span>1<\/span> <\/p>\n

        <\/span>##<\/span> <\/span>SPWebConfigModificationType.EnsureSection<\/span> <\/span>-><\/span> <\/span>2<\/span> <\/p>\n

        <\/span>$configMod2<\/span>.<\/span>Type<\/span> <\/span>=<\/span> <\/span>1<\/span> <\/p>\n

        <\/span>$configMod2<\/span>.Value<\/span> <\/span>=<\/span> “86400” <\/p>\n

        <\/span>#<\/span> <\/span>Add<\/span> <\/span>mods,<\/span> <\/span>update,<\/span> <\/span>and<\/span> <\/span>apply<\/span> <\/p>\n

        <\/span>$WebApp<\/span>.WebConfigModifications.Add(<\/span> <\/span>$configMod1<\/span> <\/span>)<\/span> <\/p>\n

        <\/span>$WebApp<\/span>.WebConfigModifications.Add(<\/span> <\/span>$configMod2<\/span> <\/span>)<\/span> <\/p>\n

        <\/span>$WebApp<\/span>.Update()<\/span> <\/p>\n

        <\/span>$WebApp<\/span>.Parent.ApplyWebConfigModifications()<\/span> <\/p>\n

    <\/span>}<\/span> <\/p>\n

    <\/span>}<\/span> <\/div>\n<\/blockquote>\n

    Reverting the Changes<\/h4>\n

    Though creating a function to automate web.config<\/strong> changes across the farm is great, what happens if you need to revert your changes? Here is another situation where the utility of SPWebConfigModification<\/strong> shines. Remember that in our previous example, we set the Owner<\/strong> property of our modifications to BlobCacheMod<\/strong>. Removing the changes now becomes a matter of once again getting a reference to the SPWebApplication<\/strong> and its WebConfigModifications<\/strong> property, sifting through the collection and finding objects with the Owner<\/strong> property set to BlobCacheMod<\/strong>, and then calling the Remove<\/strong> method on the collection for each of these. You then wrap up by calling the Update<\/strong> method on the Web Application<\/strong> object and ApplyWebConfigModifications()<\/strong> on the SPWebService<\/strong> parent object to apply the changes. Here is the complete function:<\/p>\n

    \n
    function<\/span> <\/span>Disable-SPBlobCache<\/span> <\/span>{<\/span> <\/p>\n

    <\/span>param(<\/span> <\/p>\n

        <\/span>[Parameter(Mandatory<\/span>=<\/span>$true<\/span>,<\/span> <\/span>ValueFromPipeline<\/span>=<\/span>$true<\/span>,<\/span> <\/span>Position<\/span>=<\/span>0<\/span>)]<\/span> <\/p>\n

        <\/span>[Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind]<\/span> <\/p>\n

        <\/span>$WebApplication<\/span> <\/p>\n

    <\/span>)<\/span> <\/p>\n

    <\/span>process<\/span> <\/span>{<\/span> <\/p>\n

        <\/span>$WebApp<\/span> <\/span>=<\/span> <\/span>$WebApplication<\/span>.Read()<\/span> <\/p>\n

        <\/span>$mods<\/span> <\/span>=<\/span> <\/span>@()<\/span> <\/p>\n

        <\/span>foreach<\/span> <\/span>(<\/span> <\/span>$mod<\/span> <\/span>in<\/span> <\/span>$WebApp<\/span>.WebConfigModifications<\/span> <\/span>)<\/span> <\/span>{<\/span> <\/p>\n

            <\/span>if<\/span> <\/span>(<\/span> <\/span>$mod<\/span>.Owner<\/span> <\/span>-eq<\/span> “BlobCacheMod” <\/span>)<\/span> <\/span>{<\/span> <\/p>\n

                <\/span>$mods<\/span> <\/span>+<\/span>=<\/span> <\/span>$mod<\/span> <\/p>\n

            <\/span>}<\/span> <\/p>\n

    <\/span>}<\/span> <\/p>\n

        <\/span>foreach<\/span> <\/span>(<\/span> <\/span>$mod<\/span> <\/span>in<\/span> <\/span>$mods<\/span> <\/span>)<\/span> <\/span>{<\/span> <\/p>\n

            <\/span>[void]<\/span> <\/span>$WebApp<\/span>.WebConfigModifications.Remove(<\/span> <\/span>$mod<\/span> <\/span>)<\/span> <\/p>\n

        <\/span>}<\/span> <\/p>\n

        <\/span>$WebApp<\/span>.Update()<\/span> <\/p>\n

        <\/span>$WebApp<\/span>.Parent.ApplyWebConfigModifications()<\/span> <\/p>\n

    <\/span>}<\/span> <\/p>\n

    <\/span>}<\/span> <\/div>\n<\/blockquote>\n

    So there it is. Two functions, Enable-SPBlobCache<\/strong> and Disable-SPBlobCache<\/strong>, which take a Web Application<\/strong> object from the pipeline or via command-line input and make the necessary web.config<\/strong> changes to enable or disable the BlobCache<\/strong> across the farm. Other changes to web.config<\/strong> files can be automated in the same way.<\/p>\n

    I typically wrap these and other custom cmdlets into a module and import the module into my SharePoint Management Shell when I need the functions. You could also create a script and dot-source it, or create a script that defines the functions and then calls them. The choice is yours.<\/p>\n

    There are many other opportunities in Windows PowerShell to simplify and unify cross-farm and cross-component administration in a SharePoint farm. Stay tuned for future posts.<\/p>\n

     <\/p>\n

    JG, that is all there is to using Windows PowerShell to automate changes to the SharePoint 2010 web.config<\/strong> file. Guest Blogger Week will continue tomorrow when Glyn Clough will talk more about SharePoint.<\/p>\n

    We invite you to follow us on Twitter<\/a> and Facebook<\/a>. If you have any questions, send email to us at scripter@microsoft.com<\/a>, or post your questions on the Official Scripting Guys Forum<\/a>. See you tomorrow. Until then, peace.<\/p>\n

     <\/p>\n

    <\/strong><\/p>\n

    Ed Wilson and Craig Liebendorfer, Scripting Guys<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

      Summary: Learn how to use Windows PowerShell to script changes to the web.config file on SharePoint 2010.   Hey, Scripting Guy! I need help using Windows PowerShell to automate making changes to the web.config file on my SharePoint 2010 farm. Do you know of a way to automate making these changes? — JG   […]<\/p>\n","protected":false},"author":595,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[56,187,3,59,45],"class_list":["post-17121","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-guest-blogger","tag-josh-gavant","tag-scripting-guy","tag-sharepoint","tag-windows-powershell"],"acf":[],"blog_post_summary":"

      Summary: Learn how to use Windows PowerShell to script changes to the web.config file on SharePoint 2010.   Hey, Scripting Guy! I need help using Windows PowerShell to automate making changes to the web.config file on my SharePoint 2010 farm. Do you know of a way to automate making these changes? — JG   […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/17121","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/595"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=17121"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/17121\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=17121"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=17121"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=17121"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}