Bypass Powershell ExecutionPolicy

In attempting to do some Powershell (WinRM) remote actions, specifically using  Roger Zander's Collection Commander, I came across this blog entry and thought "Awesome, already done for me!".

And then I kept getting errors during testing, "Exception calling "Install" : ""  But it would work fine in the home lab... After much head scratching, at work we have a GPO to set Powershell ExecutionPolicy as RemoteSigned--which is good, of course.  But it threw this particular script for a loop.  In the home lab--since it is a home lab--I had set executionpolicy to unrestricted on the test box.

What I ended up doing was I found this blog post about different ways to get around a remote-signed execution policy (in a good way, not trying to do evil things):

The one which was the easiest to implement for these specific needs was the "Bypassing in Script" one detailed here:

Create ConfigMgr Powershell Configuration Items using Powershell

As part of a presentation for the 2019 Midwest Management Summitin Minneapolis, one of the sessions I'm presenting with Jeff Bolduanis Configuration Items.  As part of that session, we'll be demoing using a PowerShell Script to create PowerShell-based Configuration Item.
If you want to see how that works (at least it works in my lab) --> Here<-- is the script for creating a Configuration Item with multiple tests inside, where the CIs are posh-based detection, applicability, and remediation scripts.  For demo purposes, I grabbed the scripts from the blog --> about WSUS Administration/WSUSPool <-- settings enforcement via Configuration Items, and got them all working to be made into 1 Configuration Item, with multiple rules.
Hopefully for those of you who are looking to create your own re-producible PowerShell code for creating posh-based CIs, the attached example posh will give you an idea of how you might want to get that done.

POSH for adding Security Updates to a Software Update Group in CM12

Ever used ADRs (Automatic Deployment Rules) functionality in CM12?  Use it!  Granted, the search engine in there could use some work, but it's probably the best feature that was added in CM12!   I have to give my buddy Mason credit for this, for he has a lot to do with this addition :).

Anyway, we leverage ADRs in our environment for simply downloading the Monthly patches. Then we just turn around and add these downloaded patches to our Monthly patching groups with a deployment set to it. Well ok, we’ve automated the monthly downloads, now I kind of wanted to automate the group membership addition step here, for managing and patching our own servers. Well, how do we do that without having to recreate the patch deployment to our servers or kicking off the patch installs on our servers right away and impacting them?   Granted we have maintenance windows set for them, but we still wanted to tightly control this process and set the deployment deadline time appropriately in the future. So the answer is, we set the Update deployment to our Pilot collection first (to avoid impact), then add the newly downloaded patches from the ADRs to our group. Then modify the existing deployment’s deadline time later when pilot servers are validated.

So the POSH script below is what I had put together for this process.   So after the ADRs are done downloading, intent is to run this script and here’s what it does:

  1. Loads the CM12 PS module and connects to the CAS
  2. Sets or points the existing deployment to our pilot collection
  3. Then it grabs the downloaded updates from the ADR groups, and add them to our Software Update Group

NOTE: You can change that Pilot collection to an Empty collection, for added safety measures.  And this also ensures that itanium updates are not added. For every now and then, those clowns get added in our group somehow. So this should avoid that. Oh, this would also go hand in hand with my other script/posting “Posh to remove expired and/or superseded updates from a CM12 Software Update Group”.

Use it at your own risk! :)

POSH for clearing DELL OMSA Logs Remotely

Ever get tired of having to login remotely to DRACs and clearing the logs that way?   Here's a quick POSH for doing the same, but saves a lot of time.  Gotta love invoke-command :).   I suppose you could use PSEXEC too, but that's so 80s. :)


For clearing Individual servers example

Invoke-Command -Computername MYSERVER01 -ScriptBlock {omconfig system esmlog action=clear}


Or by group or list of servers Example

Invoke-Command -Computername (Get-Content "C:\ServerList.txt") -ScriptBlock {omconfig system esmlog action=clear}




POSH for Switching from using non-shared to shared SUPDB on CM12 SUPs

It is generally recommended to use shared SUSDB In your CM12 environment when you have multiple SUPs (Software Update Points) in a single primary site. Thus, have you ever had the need to switch from using SUPs with their own SUPDBs to shared SUPDB?   We did this simply to avoid the clients in failed state for long periods and to avoid that network cost.   Below is the script that I put together to switch from using non-shared SUPDB to shared SUPDB on our SUPs>

This script pretty much follows the general guideline of setting up your SUPs with shared SUPDB.   However, since we had already had it set in place where our SUPs were already using their own SUPDBs, so this will uninstall WSUS off your existing SUP or remove the role (windows feature) so that it can reset which DB it’s pointing to.   Then it follows it up with post configuration to put things back, and to where your SUPs are pointing to that single or common shared WSUS Database.

General guideline of installing multiple SUPs with Shared SUPDB.

  1. Prepare the Database server, create the share (WSUSContent) and create the WSUS group that has access to the share
  2. Install the first SUP with WSUS pointing to the common SUPDB and move its content to a Central\shared location (copy content)
  3. Install the subsequent SUPs with WSUS pointing to the common SUPDB and move its content to a Central\shared location (-skip copy)


Here’s what the menu prompt looks like:



Quick breakdown of what each above does:

DB option

  • Creates the WSUSContent directory and shares it out
  • Then it creates the local WSUS Content group


  • Removes the role and adds it back
  • Runs the post configuration using WSUSUTIL and points to the remote SUPDB
  • Runs the post configuration using WSUSUTIL and moves the content
  • Adds the SUP1 computername to WSUS Administrators group that has access to the content
  • Sets the Virtual Content access to use a service account (Change user and pass in this the script)


  • Removes the role and adds it back
  • Runs the post configuration using WSUSUTIL and points to the remote SUPDB
  • Runs the post configuration using WSUSUTIL and moves the content with -skipcontent
  • Adds the SUP1 computername to WSUS Administrators group that has access to the content
  • Sets the Virtual Content access to use a service account (Change user and pass in this the script)

Lastly, this creates a log in the same folder you run this script under. $scriptname.log.

Again, use this at your own risk! But I hope it helps! J



  • Script only supports Windows Server 2012 and/or Windows Server 2012 R2
  • The WSUSDB server also holds the WSUSContent share here as well. You can change that in the script if you’d likeJ. And it obiously requires IIS on the SUPDBJ
  • Run this script locally on the box you are working on. You will need to run this on the remote database server first to prep the DB. Then run it on the SUP1, SUP2 SUP3 and so on, following the guideline above.
  • Pay attention to the variables that are set above the script.   And it is domain aware, so change the variables in there according to domain environments you have. This is really useful for folks that have Lab and production environments. So you only make one script change and it applies to both for consistency.





POSH to import new machine objects for imaging along with OSD Variables

For the longest time, i couldn't find a good way to quickly and easily import a machine in CM12 for imaging along with necessary OSD variables to properly image our servers/workstations.  Now that we have CM12 R2, a new cmdlet "New-CMDeviceVariable" is put to use!  Here's a POSH i put together for importing new machine(s) in CM12 along with OSD variables.   It reads the .CSV file you provide (will be prompted for the path and name for it) and import the machines that are in that file, line by line.  This script also detects which domain you're in so you can set certain variables for let's say working you're in Lab or in your Production environment.   Just crack this posh open and change necessary variables in there to match your settings.   Below is the script, along with a sample .csv with required formats.  





POSH to remove Expired and/or Superseded Udpates from a CM12 Software Update Group

Up to this date, there’s still not a CM12 cmdlet that would help remove updates from Software Update Groups.   It makes it cumbersome on the monthly basis to remove the expired and superseded from these groups… Just a lot of clicking! :) Here’s a PowerShell code that I threw together to try to reduce the my mouse clicks every patch cycle :).   This code will prompt you for which you'd like to process or remove from the given group, E for expired or S for superseded.   I suppose i could add that as another parameter, but then it'd be too much typing :).   Alright, I’m fairly new to POSH, so don’t judge!

Usage :  Remove-ExpAndSuperseded.ps1 <CAS Server Name> <sitecode> '<Target SUP Group>'


Updated: 7/8/2014

Use CM Console scripts node to gather log files from CM Clients

To assist in answering a question in this forum post:

I'm blogging on behalf of Srikant Yadav; he gave me permission to do so.  Thanks Srikant! 

How to make this work..

Step 1:
Make a location on a server you manage/control--which has lots of space.

create a folder called (for example):

Share that out as ClientLogs$
At a minimum, you need these permissions (if you have multiple domains, or support non-domain joined computers, you'll have to figure out what other permissions might be necessary).

 For share permissions, because who will be 'copying' the logs to that share is a computer, add the group:
  <your domain where your computers live>\Domain Computers, with Change, Read.
 On that folder of E:\ClientLogs, for NTFS permissions, add Modify, Read & Execute, List folder contents, read, Write (aka, everything but full control) to
  <that same group you just did for share permissions, aka, \Domain Computers

Step 2:
In the --> attached <-- is a script.  Modify the parameter within that script which is currently...
$Destination = "\\<DummyShare>\ClientLogs$"

To be  \\YourServer\ClientLogs$

Save that modified script as <some location you'll remember>\ImportThisIntoCM.ps1

Step 3:
In your CM Console, go to software library, scripts, create script
ScriptName = Retrieve Client Logs
Script Language = Powershell
Import... and go to <some location you just said you'd never forget> and import that ImportThisIntoCM.ps1 script.
Review the Script Parameters.  You can, if you wish, modify the defaults of the parameters here.  For example, maybe you ALWAYS want to get any ccmsetuplogs, or you know you only want log files that will be within the last 5 days and nothing older.
double-check the Destination is the right servername and sharename
Next, Next, Close.

Step 4:
Approve the script in the Scripts Node.  You may need a peer to do the approval.  In smaller environments, if you are the only admin, you can self approve scripts in the Scripts node if you've configured that in Site Configuration, Site, Hierarchy Settings, uncheck "do not allow script authors to approve their own scripts".  This is a safety feature, that you SHOULD leave checked--because scripts can be powerful.  Some disgruntled admin COULD make a "format c:" type of script, self approve it, and send it as they walk out the door.  Just saying... you might not want to do this.  peer review of scripts is GOOD.

Step 5:
Use it!
As an example, in Assets and Compliance, Devices, pick on a Online device (obviously this only works if the target is online/available), right-click, Run Script.  Pick "Retrieve Client Logs".  At this point, you can change parameters as needed.  Next/next.  You'll see a progress bar. 

When it's done, in the \\yourserver\ClientLogs$ will be Subfolders; CMClientLogs$ for cmclientlogs, WindowsUpdateLogs$ for WindowsUpdateLogs, etc.  Inside those subfolders will be the zipped-up log files, named for the device name targeted.

Step 6:
Have a Cleanup Routine.  The \\YourServer\ClientLogs$ doesn't have any automatic cleanup routine around it.  If say... you were to gather log files all the time, wherever that location exists might fill up the drive.  You want to remember to clear that out either manually occasionally, or setup some kind of maintenance routine on that server to "delete xx when older than yy days" or something.

Possible updates...If you read through the script, you'll see that you can make this extensible yourself.  Perhaps you have a <App Specific to our type of business> which has log files that are always stored in c:\programdata\Widgets\Logs.  You can easily add a new section to the script, with another parameter to grab those log files as needed, if needed.

Copyright © 2022 - The Twin Cities Systems Management User Group