Home » Exchange Server » Using an XML Settings File for PowerShell Scripts

Using an XML Settings File for PowerShell Scripts

One of the most common feedback items for PowerShell scripts that I've published, such as Test-ExchangeServerHealth.ps1, is that having to edit the script to insert the correct email settings is a pain. The other is that the scripts are unsigned, requiring the execution policy of the machine running the script to be relaxed.

These two things go hand in hand. I don't sign the scripts because they always need editing to work in your environment. And I include the settings that need editing in the script, instead of making them parameters, because I want the script to be easy to run (a lot of parameters seems to increase the number of “How do I…?” questions I get).

To solve these issues, at least partially (people may still choose to edit scripts to customize their operations in other ways), I am looking at breaking these settings out into a separate file instead.

Here is a demonstration of how this would work. I've created a simple demo script and Settings.xml file to go with it.


The PowerShell script is quite simple – it sends an email message.

The script imports the Settings.xml file to determine the various email settings it should use.

The XML file itself is also quite simple.


The script uses the data in the XML file to set parameters for the email message. Values can still be set directly in the script (like the email subject below), but I think it will make more sense to put them in the XML file instead.

When the script is executed an email message is sent. Simple as that.

This concept extents beyond just the email settings for scripts. Several of my scripts also include other variables such as alert thresholds, text strings for different languages, and so on. The more of these that are moved into a Settings.xml file like the above demonstration uses, the fewer reasons there will be to edit a script file directly.

If you have any feedback or comments on this I'd love to hear them.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server


  1. Michel de Rooij says:

    Depends on the purpose. To maximize flexibility and general purpose usage, I parametrize stuff. Yes, that will increase erroneous usage but I see that as part of the learning curve of the one running the script. For testing or repeated usage, I use splatting for all or specific parameters like you do yourself (‘@’), you only read them from an XML in your script. Downside is that this creates a dependency (on that file) and requires proper syntax and XML (where some characters aren’t allowed). On the plus side, they can send you that XML to try to reproduce issues etc. or you can use it to run scheduled jobs (without zillions of parameters). I use an XML file for my Install-Exchange2013 script to save parameters and state information in between reboots.

  2. Me says:

    No complains here:)
    I don’t think its a lot of work to edit a script somebody talented like you wrote.
    Thanks for the effort you put into it

  3. Richard Voogt says:

    Nice way to use the script in many different enviroments, like i do.
    Thanks for the hint, i’m going to use this in my scripts.

  4. Richard A says:

    @Paul Cunningham – On the previous version of Get-DailyBackupAlerts it was posssible to have multiple recipients in the To field. This was achieved by seperating each in inverted commas, with a comma between (e.g. From = “1@xyz.com”,”2@abc.com”,”3@aaa.com). This no longer seems possible with the Settings.xml file. Please would you advise me how to do this?

      • Mike says:

        @Richard and Paul

        A bit late but I had the same problem as you Richard.

        When setting the $smtpsettings hashtable, I changed the ‘To’ key to be:

        To= @($ConfigFile.Settings.EmailSettings.MailTo.Split(“,”).Trim())

        The XML line is:

        MailTo>user1@domain.com,user2@domain1.com etc.

        This seems to have done the trick.


  5. Wouter says:

    How to access the path of the script? I want to be able to just put the script and it’s config anywhere and let the script read the config file from the same folder. Regardless of where the script is called from.

    • James L says:

      Use $PSScriptRootsettings.xml

      This will prefix the the settings.xml path to the same as the script that executed it.

Leave a Reply

Your email address will not be published. Required fields are marked *