1. If you are running Windows 10 and Windows Server 2016, you can use the Set-SmbServerConfiguration cmdlet and the AuditSmb1Access parameter to configure SMB1 auditing by running the command: Set-SmbServerConfiguration –AuditSmb1Access $true (You can then review the Microsoft-Windows-SMBServer/Audit log for any events indicating SMB1 activity)
2. Talk to your network or security team to see if there is anything that they can enable on your organization’s routers and switches that can log traffic throughout your environment to see if SMB1 is being used anywhere.
3. Perform network captures on systems that you suspect may be communicating with devices that only support SMB1. System design documents can be useful here to point out the expected communication flow for a deployed application. It is also worth noting that end user client systems can sometimes act as SMB servers, so they should be evaluated too and their traffic analyzed if needed. Clients can talk to seemingly innocuous devices that run SMB1, like printers, NAS, manufacturing gear, etc. that themselves aren’t running Windows but Samba/Linux, and they would need to be investigated in some promiscuous fashion.

PS C:\> C:\Users\username\Documents\DSCEA> Start-DSCEAscan -MofFile .\localhost.mof -ComputerName dsctest-1, dsctest-2, dsctest-3

PS C:\> C:\Users\username\Documents\DSCEA> Get-DSCEAreport -Overall -InFile 'C:\Users\username\Documents\DSCEA\results.20170406-2309-05.xml' -OutPath 'C:\Users\username\Documents\DSCEA'

PS C:\> C:\Users\username\Documents\DSCEA> Get-DSCEAreport -Detailed -InFile 'C:\Users\username\Documents\DSCEA\results.20170406-2309-05.xml' -OutPath 'C:\Users\username\Documents\DSCEA'

• Introduced exciting new updates to Start-DSCEAscan
  • Automatic copying of any custom resources needed for a scan from the management system to the remote endpoints being scanned
    • Thank you to Anthony Watherston for adding this capability to DSCEA!
  • Added a new Path parameter, which allows Start-DSCEAscan to take in a folder path containing machine specific MOF files to allow for a scan of those systems against unique per system settings
• Added additional config examples
  • Config that uses non built-in DSC resources
  • Config that showcases using the DSC script resource
    • Thank you to Patrick Mercier for your contributions and feedback on this!
• Bug fixes
  • Fixed issue where errors were thrown when running Import-Module DSCEA
    • Thank you to Melissa Januszko for pointing this out!
  • Fixed quote character issue when running Get-Help Start-DSCEAscan
• Documentation updates
  • Clarified instructions on Report Generation with Power BI page
    • Thank you to Zachary Alexander for updating this page!
  • Clarified instructions on PowerShell Gallery - Offline Install page
  • Added page - Convert DSCEA scan result to CSV
  • Added page - DSCEA Functions Reference

• Verifying a single setting, for example if a registry key is set appropriately across your entire environment
• Auditing your systems to ensure that they meet the base level system configuration settings that are required to be a part of your environment
• Scanning the systems in your environment against all of the items that make up your organization's security baseline
• Verifying that settings configured via Group Policy are being applied correctly to the systems in your environment
• Verifying settings configured on Windows Server 2016 Nano servers (which do not support Group Policy)

Scan multiple systems for compliance to settings defined within a localhost.mof file located in your current directory

PS C:\> Start-DSCEAscan -MofFile .\localhost.mof -ComputerName dsctest-1, dsctest-2, dsctest-3

Generate HTML Reports based on scan results - System Compliance

PS C:\Users\username\Documents\DSCEA> Get-DSCEAreport -Overall

Example HTML Report #1

PS C:\Users\username\Documents\DSCEA> Get-DSCEAreport -Detailed

Example HTML Report #2

Feeling creative?  DSCEA XML data can be converted into CSV, for use with other tools like PowerBI

Looking at the syntax and examples for the ArgumentList parameter, I was unable to find any details for using it with a set of input parameters, so once I was able to pull something together that worked I figured it would be worth to share a full example of this functionality in action.

Example script basicremoting.ps1

To configure things to be non-interactive and not require an administrator to be at a keyboard for the script to complete successfully, I have chosen to simply use the Invoke-Command cmdlet on its own.  If you utilize PowerShell throughout your day, hopefully you are running the latest production release, PowerShell version 4.  If you are running PowerShell version 4 and are looking to get this to work, some additional configuration is needed on each SharePoint server that you want to run remote commands against.

Assuming that you have configured WinRM and your remote SharePoint server is capable of handling PowerShell remote commands, we will start with a simple example that should work without any additional configuration:

Invoke-Command -Computer SP2010 –ScriptBlock {
Get-Host
}

Saving the above code as a ps1 file allows us to run this simple PowerShell script against a remote computer called SP2010 from our management server.  It is always a good first step to ensure that your script works properly outside of your automation environment before you try to add it in, so I do all my testing first just against the ps1 files themselves.

Let’s dig deeper now that we know remoting is working, and let’s come up with a simple script that utilizes a SharePoint cmdlet

Invoke-Command -Computer SP2010 –ScriptBlock {
Add-PSSnapin Microsoft.SharePoint.PowerShell
$farm = Get-SPFarm
}

If you are up to date with PowerShell and running version 4 throughout your environment, the above command will fail.  The reason is that the SharePoint snapin that is referenced is not compatible with version 4 of the .Net Runtime, which is used by default in PowerShell version 4.  You may have come across this already as well and you may be thinking, “I already have a way to fix this, I just need to run powershell -v 2 before I go to add the snapin.”  And again you would be right, except this only works in an interactive session.  Since we are trying to do this non-interactively so it can be run any time by Orchestrator, we need to find a different solution.  The issue with this comes up when we try to run the Invoke-Command cmdlet, as the Invoke-Command will never complete when the powershell –v 2 option is included in your script.

This led me to do some searching, and I came across the following article by Cyril Leroy https://www.gsx.com/blog/bid/86424/Allow-Remote-PowerShell-on-SharePoint-2010-and-PowerShell-v3

In their post, Cyril demonstrates the Set-PSSessionConfiguration cmdlet.  Using this cmdlet, we can force a computer to use a desired version of PowerShell when we connect into it to execute remote commands.

On each SharePoint 2010 server that has PowerShell version 4 installed, we will run the following command to force the server to run remote commands using PowerShell version 2.  While this seems similar to the powershell –v 2 command we talked about earlier, the difference here is that this configuration will still allow us to run the Invoke-Command cmdlet.

Set-PSSessionConfiguration -Name microsoft.powershell -PSVersion "2.0"

Upon running this command, we can head back over to our management server and run our script that contains our SharePoint cmdlets and the Invoke-Command to our remote SharePoint server and things should now complete successfully.

In that post, Diego provided a great example of using the Routing and Remote Access Service (RRAS) that is built into Windows Server 2012 R2 to setup a site to site (S2S) VPN to an Azure subscription.  In regards to Azure, the benefit of a S2S VPN is that it allows you to extend your on-prem network to a virtual network hosted in your Azure subscription.  By extending your network, you can extend your data center and build machines in your Azure environment and integrate those machines directly with your on-prem environment.  RRAS is a supported mechanism for setting up a S2S VPN, but it has requirements that can prove difficult for small lab environments, like requiring multiple public IP addresses.  This caused RRAS to be less than ideal in lab type scenarios, especially home labs.  I found Diego's solution to the issues posed by these requirements to be very helpful as it allowed me to setup a VPN connection using NAT IP's from my on-prem environment up to the virtual machines I have running in my Azure subscription.  This is really the first requirement that had to be met in order to add Azure machines to my on-prem hosted domain, because in order to be members of the domain, a network connection tying my on-prem environment to the machines hosted in my Azure subscription had to exist.  I had put this off for a while, as I didn't want to invest in a new piece of hardware to enable the VPN, and while running a VM with the RRAS role was supported, I did not want to invest in purchasing multiple static IP's from my ISP.  Upon finding Diego's example I had everything I needed to proceed with S2S VPN testing using RRAS in my home lab.

While the solution Diego explained would not be appropriate for a production environment, it should more than fit the need for most small lab environments, and it did everything I needed to get things up and running in my home lab.

Continuing from the end of Diego's post, the next steps I had to complete involved configuring a static route for machines in my on-prem network, to tell them to use the NIC labeled "Internal" on my RRAS server as the gateway to reach machines that were being hosted in my Azure subscription.  Following Diego's post, the VPN connection had been established between my on-prem environment and my Azure subscription, but I was only able to communicate to and from my Azure VM's with my RRAS server.  It was not until I configured the static route on my core router in my on-prem environment that I could reach all of my on-prem resources from my Azure VM, most importantly being my on-prem domain controllers.

Additionally, I configured my Azure network with the IP of my on-prem DNS server so that when machines were created in Azure that were part of my virtual network, they would automatically get my on-prem DNS server as a DNS server in their network configuration.  This is important so that when I try to add a machine to my on-prem hosted domain, the server in Azure that is being added to the domain has the ability to resolve the domain name properly.

With these steps completed, I was able to successfully join one of my machines hosted in Azure to my domain hosted solely on-prem, and begin managing that machine just as I would any other server in my on-prem environment.  For me, the biggest hurdle I had to overcome was the static route configuration, so if you are looking to get this setup I hope this information can be useful to you!

In that post, Neil explained how we could use PowerShell to place cluster nodes into maintenance mode in Operations Manager when a Cluster Aware Update job was run.  Neil looked at placing a cluster node into Operations Manager maintenance mode, and in this post I will show how we can take a node out of maintenance mode once it has finished applying updates.

In the screenshot from Neil’s post below, we see that he setup an Updating Run Profile that specified a PowerShell PS1 file to act as a PreUpdateScript.  This PS1 file was written to place the node being updated by Cluster Aware Updating into Operations Manager maintenance mode.  For our purposes, we will show how to create a new PS1 file to take a node out of maintenance mode once updating has completed.  Our goal is to restore monitoring on the cluster node as soon as possible once updating has finished for that node.  We would look to include this new PS1 file as our PostUpdateScript in our Updating Run Profile.  Without the PostUpdateScript, the node will stay in maintenance mode for the entire period that was specified in the PreUpdateScript, unless an administrator ends the maintenance mode early.  Through this example we look to show how that can be handled automatically.

Looking at the PowerShell code provided by Neil, I saw it included the start-scommaintenancemode cmdlet.  So in my first attempts to setup the PostUpdateScript, I looked to see if I could find a stop-scommaintenancemode cmdlet.  Sadly it was not that easy, as such a cmdlet does not exist.  But the silver lining is that it gave me a reason to put together this post, and hopefully help others out looking for a solution to this.

Through some research, I learned that while there is not a stop-scommaintenancemode cmdlet, there is a StopMaintenanceMode method.  Using the following example from Boris Yanushpolsky for SCOM 2007, I found that the StopMaintenanceMode method is still valid in Operations Manager 2012 R2, and I was able to borrow the following code from Boris’ post:

$computer.StopMaintenanceMode([System.DateTime]::Now.ToUniversalTime(),[Microsoft.EnterpriseManagement.Common.TraversalDepth]::Recursive);

This method allowed me to end an active Operations Manager maintenance mode immediately, and the recursive setting ensured that all monitors underneath the Windows Computer object exited maintenance mode as well.

Full code to my PostUpdateScript PS1 file:

$secpasswd = ConvertTo-SecureString "<Password>" -AsPlainText -Force

$mycreds = New-Object System.Management.Automation.PSCredential ("<DOMAIN\user>", $secpasswd)

$ComputerName = [System.Net.Dns]::GetHostByName(($env:computerName)).HostName.ToString()

Invoke-Command -ComputerName <SCOMServer> -Credential $mycreds -ScriptBlock {

   import-module operationsmanager

   $class = get-scomclass -name:’Microsoft.Windows.Computer’

   $computer = get-scomclassinstance -class $class | where{$_.name -eq $using:ComputerName}

   $computer.StopMaintenanceMode([DateTime]::Now.ToUniversalTime(),[Microsoft.EnterpriseManagement.Common.TraversalDepth]::Recursive);

}

This code can then be saved as a PS1 file, and specified in an Updating Run Profile as a PostUpdateScript.  This is just a small example of what is possible using PowerShell to customize updates via the Cluster Aware Updates option, but I hope you found it useful!