We all know I have OCD when it comes to formatting. Using the built in PowerShell cmdlets (Export-XmlCli) to export XML left me with a mess of an XML Schema that I couldn’t apply a XSL Transform to. I needed something that would allow me to control the schema, and insert the XSL declaration. After doing quite a bit of online searching and research, I decided to try using the .NET class System.XML.XmlTextWriter. The code sample below is the basic snippet using the class and creating a document.

A couple of notes:

• $filepath will need to be set to the full file path, using “.\” will not work.
• If you are creating a complex file, you will want to note which tag you are closing with the WriteEndElement.

Service Accounts are a necessary evil in systems administration. They tend to be shared across members of a team, have access to sensitive data and critical infrastructure. Yet, most companies have minimal safeguards in place for these accounts, and even less policy and procedure in place to govern these accounts. Service accounts don’t need to be a security threat, with a few simple Group Policy Objects and a little planning these can be the most secure accounts in your domain.

In my past life as a consultant, I ran across an unusual exploit that was created when someone added an autorun.inf to the root of the company shared drive. This exploit infected the systems with malware that was easily removed, but it could have been worse. As a result, I have created the following GPO to disable autorun at all of my clients, and is one of the first things I check when I start at a new company.

The settings for the GPO are located under Computer Configuration | Policies | Administrative Templates | Windows Components | AutoPlay Polices. The two settings are:

• Default behavior for AutoRun: Do not execute any autorun commands
• Turn off Autoplay on: All Drives

This policy is not invisible to your users! If your users have become accustomed to autorun working on certain DVDs, or CDs they may think something is wrong with their system. As always, communicate with your users about the changes you are making.

The SysAdmin PowerShell Module consists of a diverse set of functions, but there is one set of functions that is leveraged in every other function…Logging! The logging functions provide visual feedback to the user about the progress of a script. It can also provide valuable debugging information when a script goes sideways.

The logging functions consist of a core function ‘New-Log’. The function takes two parameters: (1) the log text, and (2) the type of log. The second parameter is not required. The remaining logging functions in the module call ‘New-Log’ with the second parameter. The functions are shown below:

Over the past year, I have passed from PowerShell n00b to being able to script/code anything that has been thrown at me. One of the main reasons I have been able to progress this far with my PowerShell abilities are all the great blogs and resources on the internet. I hope over time, that this blog may be a resource for those starting with PowerShell and those who want to learn more.

While I’ve been learning PowerShell, I have been compiling a PowerShell Module for Sys Admins. This module consists of a core library that handles reporting, connecting to remote servers, etc. In addition, it contains scripts for adding everything from DNS records creating, pulling system configuration information and a lot in between. As I go through the existing module, I’ve decided to rewrite and update the module. As I go through this process, I will share the various cmdlets under the PSModule category.

If you have any suggestions, please let me know!