First the cmdlets we need are in the server manager module so import that:

Import-Module ServerManager

Create your windows features xml or text file with the one of the following commands from a reference server:

Get-WindowsFeature | ? { $_.Installed } | Export-Clixml .\Features.xml

OR

Get-WindowsFeature | ? { $_.Installed } | Select Name | ForEach-Object { $_.Name } | Out-File .\Features.txt

To install these features:

$(Import-Clixml .\Features.xml) | Add-WindowsFeature

OR

$(Get-Content .\Features.txt) | Add-WindowsFeature

I prefer the TXT file and a Sort for an easy way to compare the files to easily compare of two servers.  Therefore my final scripts:

Export:

Import-Module ServerManager
Get-WindowsFeature | 
  ? { $_.Installed } | 
  Sort-Object Name | 
  Select Name | 
  ForEach-Object { $_.Name } | 
  Out-File .\Features.txt

Import:

Import-Module ServerManager
$(Get-Content .\Features.txt) | 
  Add-WindowsFeature

..and you should be all set.

Using a mix of the Security.Principal and Security.AccessControl .NET Classes you can couple this with your file share create class and get a complete set up of a file share; or, just use it to set NTFS permissions without all the file share portions in the previous post to set NTFS permissions on their own.

using System.Security.Principal;
using System.Security.AccessControl;

        public static void GrantNTFSPermissions(string FolderPath, string Domain, string Group)
        {
            // Create a new DirectoryInfo object.
            DirectoryInfo directoryInfo = new DirectoryInfo(FolderPath);

            // Get a DirectorySecurity object that represents the 
            // current security settings.
            DirectorySecurity directorySecurity = directoryInfo.GetAccessControl();

            // Add the FileSystemAccessRule to the security settings. 
            directorySecurity.AddAccessRule(
                new FileSystemAccessRule(
                    new NTAccount(Domain, Group), 
                    FileSystemRights.Modify | FileSystemRights.ReadAndExecute | FileSystemRights.ListDirectory | FileSystemRights.Read | FileSystemRights.Write, 
                    InheritanceFlags.ContainerInherit | InheritanceFlags.ObjectInherit, PropagationFlags.None,
                    AccessControlType.Allow)
                );

            // Set the new access settings.
            directoryInfo.SetAccessControl(directorySecurity);

        }

Important Note:  Passing mulitple values separated with a “|” to the FileSystemAccessRule class constructor’s parameters, allows you to set multiple options at once over mutliple calls/rewrites.

Using the ManagmentClass class (someone might be regretting the naming here) we can expose WMI in .NET.  Then, we can operate on methods of the Windows Managment Interface to create shares in C# code.

Like all Windows API work, this isn’t super clear throughout MSDN or the Internet.  I also find that Windows API return codes are a pain.  When I operate in that old schools space I try to take the next step and get a return code description method created.

Below, we create a security descriptor and share using .NET and WMI objects (with some return code flare).

Enjoy!

1) Figure out who you want access to your share.  This must be done with the use of of a Win32_SecurityDescriptor in WMI:

        private static ManagementBaseObject SecurityDescriptor()
        {
            NTAccount account = new NTAccount("NT Authority", "Everyone");
            SecurityIdentifier sid = (SecurityIdentifier)account.Translate(typeof(SecurityIdentifier));
            byte[] sidArray = new byte[sid.BinaryLength];
            sid.GetBinaryForm(sidArray, 0);
            ManagementObject Trustee = new ManagementClass(new ManagementPath("Win32_Trustee"), null);
            Trustee["Domain"] = "NT Authority";
            Trustee["Name"] = "Everyone";
            Trustee["SID"] = sidArray;
            ManagementObject AdminACE = new ManagementClass(new ManagementPath("Win32_Ace"), null);
            AdminACE["AccessMask"] = 2032127;
            AdminACE["AceFlags"] = 3;
            AdminACE["AceType"] = 0;
            AdminACE["Trustee"] = Trustee;
            ManagementObject SecurityDescriptor = new ManagementClass(new ManagementPath("Win32_SecurityDescriptor"), null);
            SecurityDescriptor["ControlFlags"] = 4; //SE_DACL_PRESENT
            SecurityDescriptor["DACL"] = new object[] { AdminACE };
            return SecurityDescriptor;
        }

It’s never easy with security….

So for an explaination of the above; first, you look up your principle using NTAccount then create a Win32_Trustee from that principal.

note:  this method can *easily* be parameterized for a domain:

        private static ManagementBaseObject SecurityDescriptor(string domain, string user)
        {
            NTAccount account = new NTAccount(domain, user);
            SecurityIdentifier sid = (SecurityIdentifier)account.Translate(typeof(SecurityIdentifier));

[...]

Then, you estable what access controll entry (ACE) you want to grant to the principal(s) using the Win32_Ace object.  The SecurityDescriptor method above includes it all.  Side note: ACL and ACE’s are the most confusing things to code in Windows for me, bar none.  It’s not easy, play with the code to taste if you need specific access and don’t forget to review the AccessMask and AceTypes to limit down from full control as needed.  To add multiple add them as comma separated DACL’s like so:

SecurityDescriptor["DACL"] = new object[] { AdminACE, MyACE, YourACE, OurACE };

2) Finally, create your share

First, create your ManagmentClass object and parameters (using your above security principal(s)) for the “Create” method of the Win32_Share.  If anything funky happens decode the response code description.

        public static void CreateShare(string FolderPath, string ShareName, string Description)
        {
            //create a ManagementClass object
            ManagementClass managementClass = new ManagementClass("Win32_Share");

            //create ManagementBaseObjects for in and out parameters
            ManagementBaseObject inParams = managementClass.GetMethodParameters("Create");
            ManagementBaseObject outParams;

            // Set the input parameters
            inParams["Description"] = Description;
            inParams["Name"] = ShareName;
            inParams["Path"] = FolderPath;
            inParams["Type"] = 0x0; // Disk Drive

            //invoke the method
            outParams = managementClass.InvokeMethod("Create", inParams, null);

            //check to see if the method invocation was successful
            uint rVal = (uint)(outParams.Properties["ReturnValue"].Value);
            if (rVal != 0 && rVal != 22) //ok if it already exists
            {
                throw new Exception(String.Format("Unable to share directory. \nReturn Code: {0} \nDescription: {1}", rVal, getCreateShareReturnCodeDescription(rVal)));
            }
        }

        private static string getCreateShareReturnCodeDescription(uint returnValue)
        {
            switch (returnValue)
            {
                case 0:
                    return "Success";
                case 2:
                    return "Access Denied";
                case 8:
                    return "Unknown Failure";
                case 9:
                    return "Invalid Name";
                case 10:
                    return "Invalid Level";
                case 21:
                    return "Invalid Parameter";
                case 22:
                    return "Duplicate Share";
                case 23:
                    return "Redirect Path";
                case 24:
                    return "Unknown Device or Directory";
                case 25:
                    return "Net Name Not Found";
            }
            return "Unknown";
        }

Write-EventLog : The source name "MyScript" does not exist on computer "localhost".

Here’s a simple way to get around that do that:

PS C:> New-Eventlog -LogName "Application"  -Source "MyScript"

Change “MyScript” to whatever you want the source element to reflect in your event log.

A more robust way of doing check, create if needed, then write and event can be seen here:

$ErrorActionPreference = "SilentlyContinue"
if(!(Get-Eventlog -LogName $LogName -Source $Source)){
     New-Eventlog -LogName "Application"  -Source "MyScript" | Out-Null
}
$ErrorActionPreference = "Continue"
Write-EventLog -LogName "Application" -Source "MyScript" -EntryType "Information" -EventId 0 -Message "Script Started."

First, I need to explain the “SilentlyContinue”.  At least in 2.0, the Get-EventLog cmdlet has problems throwing exceptions.  It doesn’t throw the exceptions correctly to be in a proper try/catch as discussed here.  It appears to throw a PowerShell error that can’t be properly try/catched.  After troubleshooting for a few hours, tracing the exception all over, I settled on a workaround.  I set the $ErrorActionPreference variable to “SilentlyContinue” and test for a NULL return from Get-EventLog.  If it’s return is NULL I create the log/source pair for logging and continue on my way.  Any following Write-EventLog executions using the same LogName/Source pairing will log without the source error since you’ve created it on the machine from now to the end of time.

If you want to expand to include some permissions catching I suggest this approach:

$ErrorActionPreference = "SilentlyContinue"
if(!(Get-Eventlog -LogName $LogName -Source $Source)){
     $ErrorActionPreference = "Continue"
     try {
          New-Eventlog -LogName "Application"  -Source "MyScript" | Out-Null
          Write-EventLog -LogName "Application" -Source MyScript" -EntryType "Information" -EventId 0 -Message "Script Started."
     }

     catch [System.Security.SecurityException] {
          Write-Error "Error:  Run as elevated user.  Unable to write or read to event logs."
     }
}
$ErrorActionPreference = "Continue"

I wanted to try and parameterize all of the options that the Write-Event cmdlet could do a little differently so the invocation of it within a script could be more standardized and much cleaner.  So, I extended my working through integrating my own Write-EventLog cmdlet further to exposes all of the power around the cmdlet without getting hung up on errors and unknowns.  Completed function script can be downloaded from here as well as viewed below:

Function Write-Event {
	<#
		.SYNOPSIS
			Write-Event function writes messages to the event log.

		.DESCRIPTION
			Write-Event function writes messages to the event log 
			after creating the logname and source if not already defined.

		.PARAMETER  $Message
			The message you want displayed in the event log body. 
			Required.

		.PARAMETER  $EventId
			The entryid number you wanted displayed in the event log. 
			Default is 0.

		.PARAMETER  $Source
			The source of the event log you wanted displayed in the event log. 
			Default is the PowerShell script name the function was invoked from.

		.PARAMETER  $LogName
			The log that you want the event loged in. Default is the Application log.
			If the Log and source pair do not exist on the machine this scirpt is 
			invoked on the pair will be created.

		.EXAMPLE
			PS C:\> Write-Event -Message "Process Started." -EntryId 0 -Information

		.EXAMPLE
			PS C:\> Write-Event "Process Started." -Information

		.EXAMPLE
			PS C:\> Write-Event "Process Failed." -EntryId 161 -Error

		.EXAMPLE
			PS C:\> Write-Event "Process Started."

		.INPUTS
			System.String,System.Int32,System.String,System.String,System.Switch,System.Switch

		.OUTPUTS
			None

		.NOTES
			Additional information about the function go here.

		.LINK

http://jeffmurr.com/blog

	#>
	[CmdletBinding()]	
	param(
		[Parameter(Position=0, Mandatory=$true)]
		[ValidateNotNullOrEmpty()]
		[System.String]
		$Message,

		[Parameter(Position=1, Mandatory=$false)]
		[ValidateNotNullOrEmpty()]
		[System.Int32]
		$EventId = 0,

		[Parameter(Position=2, Mandatory=$false)]
		[System.String]
		$Source = "PowerShellScript",

		[Parameter(Position=3, Mandatory=$false)]
		[ValidateNotNullOrEmpty()]
		[System.String]
		$LogName = "Application",

		[Switch]
		$Information,

		[Switch]
		$Warning,

		[Switch]
		$Error
	)

	$ErrorActionPreference = "SilentlyContinue"
	if(!(Get-Eventlog -LogName $LogName -Source $Source)){
		$ErrorActionPreference = "Continue"
		try {New-Eventlog -LogName $LogName -Source $Source | Out-Null}
		catch [System.Security.SecurityException] {
			Write-Error "Error:  Run as elevated user.  Unable to write or read to event logs."
		}
	}

	If ($Warning.IsPresent){	
		try { Write-EventLog -LogName $LogName -Source $Source -EntryType "Warning" -EventId $EventId -Message $Message | Out-Null}
		catch [System.Security.SecurityException] {
			Write-Error "Error:  Run as elevated user.  Unable to write or read to event logs."
		}
	}
	ElseIf ($Error.IsPresent) {
		try { Write-EventLog -LogName $LogName -Source $Source -EntryType "Error" -EventId $EventId -Message $Message | Out-Null}
		catch [System.Security.SecurityException] {
			Write-Error "Error:  Run as elevated user.  Unable to write or read to event logs."
		}	
	}
	Else {
		try { Write-EventLog -LogName $LogName -Source $Source -EntryType "Information" -EventId $EventId -Message $Message | Out-Null}
		catch [System.Security.SecurityException] {
			Write-Error "Error:  Run as elevated user.  Unable to write or read to event logs."
		}
	}
}

Get to writing to the event log!

For Starters

Here’s the script that gets my my report from a local computer:

Get-WmiObject -Class Win32_LogicalDisk -Filter "DriveType=3" |
Select-Object Name, FileSystem,FreeSpace,BlockSize,Size |
ForEach-Object {
	$_.BlockSize=(($_.FreeSpace)/($_.Size))*100;$_.FreeSpace=($_.FreeSpace/1GB);$_.Size=($_.Size/1GB);$_
	} |
Format-Table @{n='Server';e={$env:COMPUTERNAME}}, @{n='Disk';e={$_.Name}}, @{n='FS';e={$_.FileSystem}},@{n='Capacity (GB)';e={'{0:N3}' -f $_.Size}},@{n='GB Free';e={'{0:N2}'-f $_.FreeSpace}}, @{n='% Free';e={'{0:N2}'-f $_.BlockSize}} -AutoSize

Do it Remote:

Keep in mind the entire script can be wrapped around a “foreach” statement and pass in the ComputerName parameter for remote execution.

$ComputerNames = @("Server1", "Server2", "Server3")

foreach ($ComputerName in $ComputerNames) {

	Get-WmiObject -ComputerName $ComputerName -Class Win32_LogicalDisk -Filter "DriveType=3" |
	Select-Object Name, FileSystem,FreeSpace,BlockSize,Size |
	ForEach-Object {
		$_.BlockSize=(($_.FreeSpace)/($_.Size))*100;$_.FreeSpace=($_.FreeSpace/1GB);$_.Size=($_.Size/1GB);$_
		} |
	Format-Table @{n='Server';e={$ComputerName}}, @{n='Disk';e={$_.Name}}, @{n='FS';e={$_.FileSystem}},@{n='Capacity (GB)';e={'{0:N3}' -f $_.Size}},@{n='GB Free';e={'{0:N2}'-f $_.FreeSpace}}, @{n='% Free';e={'{0:N2}'-f $_.BlockSize}} -AutoSize

}

Report What You Found:

Afterward, sprinkle in the export type you’d like (file, CSV, etc.) to deliver.

$ComputerNames = @("Server1", "Server2", "Server3")

$DiskSpaceReport = foreach ($ComputerName in $ComputerNames) {

	Get-WmiObject -Class Win32_LogicalDisk -Filter "DriveType=3" |
	Select-Object Name, FileSystem,FreeSpace,BlockSize,Size |
	ForEach-Object {
		$_.BlockSize=(($_.FreeSpace)/($_.Size))*100;$_.FreeSpace=($_.FreeSpace/1GB);$_.Size=($_.Size/1GB);$_
		} |
	Format-Table @{n='Server';e={$ComputerName}}, @{n='Disk';e={$_.Name}}, @{n='FS';e={$_.FileSystem}},@{n='Capacity (GB)';e={'{0:N3}' -f $_.Size}},@{n='GB Free';e={'{0:N2}'-f $_.FreeSpace}}, @{n='% Free';e={'{0:N2}'-f $_.BlockSize}} -AutoSize

}

$DiskSpaceReport | Export-Csv
$DiskSpaceReport | Out-File
$DiskSpaceReport | Out-GridView

The idea is a good one.  Align with a standard in your latest technologies methods used to manage yourself, making you more usable by others.

In this post I’ll offer a quick WinRM configuration PowerShell script to get this feature configured on a Windows 2008, R2, and Windows 2012 server.  I’ll also offer feedback on the security objection and what I think is the best solution for a native Windows environment since I’ve hand to handle these often in my line of work.

Configuration Simplified

Get right to it for those not wanting to read any more.  Open a PowerShell Console as Administrator on both the client and server, servers and execute:

Write-Host "Configuring WinRM for remote deployment..."
Enable-PSRemoting -Force 
winrm set winrm/config/client `@`{TrustedHosts=`"*`"`}

More detail…

For PowerShell, WinRM is the basis of many cmdlets performing remote commands and tasks.  This includes Enter-PSSession and Invoke-Command.  These cmdlets offer powerful abilities to perform tasks on a remote computer both synchronously and in parallel, asynchronously to an array object of server names.

Believe it or not (from this lengthy write up), Microsoft wanted taking advantage of the protocol easier and less of a burden to implement.  As a result, WinRM.exe comes with a “-quickconfig” option for quick local configuration of itself, complete with a set of Microsoft’s best practice defaults.  Almost too good, and I’ll get to that below.

Therefore, the easiest thing to do is to go to a cmd prompt as an admin and run to get it all started:

WinRM quickconfig

This will set up your local service with everything to get started.  Essentially, turning on the lights.

Powershell’s flavor of this command is rolled up into  Set-WSManQuickConfig.  However, these both only modify the config of the service.  For the windows firewall, Microsoft gave us another cmdlet that’s a wrapper for Set-WSManQuickConfig.  Enable-PSRemoting cmdlet performs a few other functions as well as executing the Set-WSManQuickConfig.  Things like configuring the Windows firewall (in 2.0 it creates the exception, in 3.0 it creates a rule).

If you ride the defaults of these configurations with regards to network port, any external firewalls between your client and server will need to allow tcp 5986 bidirectional for WinRM 2.0 and above, 443 for WinRM 1.1.

Even after you run the “WinRM -quickconfig” or “Enable-PSRemoting”, you’ll find commands attempted remotely like Invoke-Command or Enter-PSSession will still fail complaining about a configuration error.  The reason is that you’ve only turned on the lights, you haven’t told the bouncer who is allowed in.  Be default, these tools do not trust anyone to connect other than…localhost.  The list of allowed servers is listed in the “TrustedHost” property of WinRM configuration.  Both of these tools the default TrustedHost list is blank.

Therefore, lets get back to the PowerShell.  Its a quick and dirty solution that’s wide open and will that need to be executed on both machines you want to configure to talk remote to one another:

Write-Host "Configuring WinRM for remote deployment..."
Enable-PSRemoting -Force 
winrm set winrm/config/client `@`{TrustedHosts=`"*`"`} 
winrm set winrm/config/winrs `@`{MaxMemoryPerShellMB=`"2048`"`}

As you can guess, “*” is everyone and may not be good enough for your needs.  Below we discuss more security aspects of a quick configuration.

Locking it down

There are complex scripts on the internet that allow for the setup of servers, even doing it remotely.  Out of the box both the WinRM and the cmdlets leave you with blank TrustedHosts.  Servers that will send or receive commands from other hosts must either have a white listed “*” or the specific servernames/IP in this list before you can connect.

The next script creates a list of servers passed as a CSV file and establishes it as your TrustedHost property.  As long as a column within your CSV file contains “Server” as a heading, those values will be included in the trusted hosts configuration and applied to the machine’s TrustedHost configuration of WinRM.

param(
	[Parameter(Position=0, Mandatory=$true)]
	[ValidateNotNullOrEmpty()]
	[System.String]
	$CSVFilePath
)

function Get-ServerList {
	param(
		$CSVFilePath
	)

	$Servers = Import-Csv $CSVFilePath
	$Servers | % {$List += $_.Server + ","}

	Return $List.Substring(0,$List.Length - 1)

}

function Configure-WinRM {
	param(
		$ServerList
	)
	Write-Host "Configuring WinRM for remote deployment..."
	Enable-PSRemoting -Force 
	winrm set winrm/config/client `@`{TrustedHosts=`"$ServerList`"`}  
	winrm set winrm/config/winrs `@`{MaxMemoryPerShellMB=`"2048`"`}
}

Configure-WinRm -ServerList $(Get-ServerList -CSVFilePath $CSVFilePath)

Note:  In both examples within the explanation, I’ve up the MaxMemoryPerShellMB.  This is optional; however, I’ve found that many tools that I may need or objects that I create are heavier than the default 150 MB amount.  I’ve found that upping it to 2048 will mitigate my running out of remote memory during processing large commands like regasm or installation packages.  Mis-configuration usually results in an obfuscated -1 exit code or just instability.  It wasn’t until I popped open process explorer that I found I was hitting a limit that most bigger executables require more of.  Totally up to you, but it is part of my server buildout now along with a correct server.csv list and features.

The Remaining Security Concerns (For Windows Environments)

TrustedHosts means only these computers can connect.  Security engineers will wonder what those connections are passing, even if its in a protected zone, between the servers listed and if that’s secure.

First the obvious, SSL is an option for WinRM.  However, I caution configuring it if your talking Windows to Windows. When asked, if you should configure SSL for security loving systems folks it can be tempting to think it is better.  The balance between and security, support and use is something we all have to deal with constantly.  In banking and healthcare it constantly audited, as it should be and I understand, layers is the answer to security.  But, WinRM with WS-Management encrypts all content transmitted over the network using Kerberos and these NTLM (machine) keys.  With Windows, a minimum of 128 bit encryption (Windows 7/2008 and up) is already in place with most later OS’s pushing the AES 256 button now.

The only thing that HTTPS will do is encrypt commands differently, that can be watered down.  Not to mention give a shelf life to your configuration the length of the validity of your certificates, before they expire.  I applaud the extensiblility, but its truly overkill in a windows environment and making something that needs to remain easy too complex; hence me leaving it out of the configuration and discussing it here.

Now, if you’re leaving a Windows environment, yes; install and configure if you’re using a non Windows product to manage a Windows machine.  That’s part of the the initiative behind WS-Management, uniform cross platform communication.  Everyone OS doesn’t have the same encryption methods as Windows baked in.  For that, I’ll have to cover another day.