To mimic an application error, in order to validate the SCOM rules, we typically leverage PowerShell scripts to create faux events. We then validate that the events are picked up by SCOM and an alert is generated.

The script must be run as administrator and assuming that the ExecutionPolicy is set in such a way to allow the script to run.

## Script Variables
$Log = "System"
$Source = "TestWebSource"
$Message = "The web service is not responding"
$ID = "911"
$AlertType = "Error"
$ComputerName = "."
$RawData = ""

##Register the source
New-eventlog -logname $Log -ComputerName $ComputerName -Source $Source -ErrorVariable Err -ErrorAction SilentlyContinue

##Write to the system log
Write-eventlog -logname $Log -ComputerName $ComputerName -Source $Source -Message $Message -id $ID -EntryType $AlertType

Note: I’m using PowerShell in this post, but you can also use Eventcreate.exe https://technet.microsoft.com/en-us/library/bb490899.aspx for similar results.

Usually I’m working on a lab machine running as a non-administrative test user. Since you cannot easily elevate and run as a different user from the right-click context menu, I wrote a simple script that I thought I’d share.

Note: One thing to call out is that our lab machines have their Execution Policy set for Unrestricted.

The script:

Start-Process powershell.exe -Credential "TestDomain\Me" -NoNewWindow -ArgumentList "Start-Process powershell.exe -Verb runAs"

The following section starts the PowerShell command-line process with Start-Process prompting for user credentials. You may not need this dependent on UAC settings, as you might already get an over-the-shoulder prompt for creds during elevation.  

Start-Process powershell.exe -Credential "TestDomain\Me"

The -NoNewWindow parameter re-uses the same PowerShell command window.

Here I’m using -ArgumentList parameter to pass in the second Start-Process leveraging –Verb runAs to force the elevation prompt.

I just saved this PowerShell script to a scratch share on the lab machines, and when I need to elevate and run PowerShell as a different user. I’d just double click on the script. It’s not the most elegant code, but it gets the job done and ideally shows some fairly cool optional parameters of Start-Process.  

The Scenario:

While testing features of Service Manager 2012 (Portal, Exchange Connector) in our lab, we were generating a large amount of SRs. Ideally; after testing was completed we would close out the Service Requests. Unlike IRs in which you can easily resolved/closed from the Task bar option, Service Requests, by design, are meant to go through certain statuses (new-to- submitted, in progress to complete before they can be closed via the Task bar.

 While this is fine if you are a service desk responding to service requests, we wanted a quick option to close out our test SRs in our lab environment. With that in mind, we decided to create a quick Task bar option (calling a PowerShell script) to clean up any of our test generated SRs without having to go through the proper statuses.

For information on setting up SCSM tasks:

How to Create a Task - https://technet.microsoft.com/library/hh499040.aspx

 For Task Settings:

On the General Tab, we set the target class to Service Request so that it would be an available SR Task, and we specified our lab management pack.

For Command Line we configured it as thus:

The Command line Parameters:

Although we are launching PowerShell in the Full path to command, we wanted to hide the PowerShell command line window, and set the execution policy to allow this script run.

powershell.exe -ExecutionPolicy unrestricted -WindowStyle Hidden –command

Here, we are specifying the $Date variable that will be used to set the closed date on the SR

{$Date = get-date;

If the Service Manager modules are not loaded, the following will import the module from the default Service Manager installation path.

If ( ! (Get-module System.Center.Service.Manager )) { Import-Module 'C:\Program Files\Microsoft System Center 2012\Service Manager\Powershell\System.Center.Service.Manager.psd1'};

The snippet below is getting the SM class instance and service request class, I’m also specifying the SM management server with the ComputerName option.

Get-SCSMClassInstance -class (Get-SCSMClass -ComputerName <SCSMServer> -name system.workitem.servicerequest) - ComputerName <SCSMServer>

Setting the Filter on the selected work item type.

-filter '"Id -eq $Context/Property[Type='CustomSystem_WorkItem_Library!System.WorkItem']/Id$"'

 Setting the closed date based on the $Date parameter

  %{ $_.ClosedDate = $Date ; $_ }

Adding implementation notes signifying that this SR was closed by a console task.

%{ $_.Notes = '"Closed by console task"'; $_ }

Setting the SR status to Closed

%{ $_.Status='"ServiceRequestStatusEnum.Closed"'; $_ }

And finally, updating the instance.

update-SCClassInstance}

Hopefully this example demonstrates how you can leverage SCSM CmdLets, along with console Tasks to add additional functionality to fit your business needs.

A big thank you goes out to Andrew Barton for assistance with the script..

Sorry I’m a bit late in posting this, but as promised in the previous post. Here is part two.

The table shown below lists the genericized steps of a task sequence created by P2V Migration Toolkit. The main thing to note, that isn’t reflected in this table, is the inherent failsafe built in to the task sequence in that if any of the virtualizations steps fail (non-zero return code), the task sequence will exit. This is designed to ensure that, for any reason, the physical-to-virtual migration was not successful the task sequence will not continue on with the re-installation of the operating system.

This is going to be a two part post…

In this initial post, I’ll define each of the programs that are called during the task sequence. In part two, I’ll list the steps of task sequence.  

The bitmap above is a pretty good summary of each component, but I wanted to provide a little more detail in this post.

• VHDCapture.exe:  This executable is leveraged by the task sequence to create an exact replica of any of the selected MBR-based physical disks and convert them into Virtual Hard Drives (VHDs). The parameters that are passed to it, in form of tasks sequence variables specify the VHD file save location as well as the disk and partition selected.
• VHDPrep.exe: Once the VHD(s) are created, this executable is called by the task sequence. Its job is to perform ‘fix-up’ and compact the disk. ‘Fix-up’ is a term we’ve used to denote the following:
  • Injects critical boot drivers to allow the VHD to properly boot
  • Correct NT Boot Sector issues for Windows Server 2003
  • Align the physical disk layout to virtual disk layout
  • Modifies boot entries to leverage virtual storage drivers

Finally, VHDPrep compacts the selected virtualized disks removing any unused space to reduce the overall file size the VHDs.     

• VMCreator.exe: This executable singular job is to configure Hyper-V specific settings and attach the VHD(s) as Hyper-V Virtual Machines. VMCreator consumes the defined task sequence variables to set the Virtual Machine name, configure the amount of memory to be utilized by the VM as well as creating a Hyper-V network bound to the specified NIC.  

Hopefully this post was helpful in providing a deeper understanding of what is actually happening “behind the scenes” of the P2V Migration Toolkit task sequence. Stay tuned for part two!

Cheers,

            -Ben

https://www.mms-2011.com/topic/details/BA17

Chris is giving a presentation around running Configuration Manager virtualized. I’ll be assisting, and running a demo for the presentation.

What AppLockerLet is doing programmatically is the following:

1.        Imports the AppLocker PowerShell Module (Import-Module AppLocker)

2.        Queries the AppLocker Event Logs to determine app that where blocked.

3.        For each blocked app determines the file location using FilePath and signing certificate information gleaned from the event log

4.        From the FilePath it’ll query the binary itself to grab the file hash, again using Get-AppLockerFileInformation

 Get-AppLockerFileInformation -path "C:\ test.msi"

5.        For the selected application – It’ll create an AppLocker rule, leveraging New-AppLockerPolicy, setting the rule type to create a hash rule, then path (if the hash information cannot be pulled for some reason).

 New-AppLockerPolicy -user Everyone -ruletype hash, path

6.        Finally, it’ll set the AppLocker policy, using Set-AppLockerPolicy, for the specified local rule, and specify it to merge as to not overwrite any other local AppLocker rules.

 Set-AppLockerPolicy –merge

Some notes on the tool – Since the UI is written in managed code it requires .Net Framework 3.5 sp1. Also to create the local AppLocker rules, you’ll need to have administrator privileges. Also AppLockerLet will need to have a corresponding AppLocker allow rule created, so that it will not be blocked via policy.  

AppLockerLet is not officially supported. AppLockerLet is solely meant as a demonstrational application to show an example of how one can wrap the AppLocker cmdlet functionality into something that can help automate a part of the AppLocker maintenance workflow.

Special thanks goes out To Brian Wishan for helping with the development of AppLockerLet.

Finally, you can download AppLockerLet from the link below.

AppLockerLet.zip

A key area that we focused on was creating a process to handle end-user ‘emergencies’, if the application was a business critical app that somehow missed our initial inventory of allowed software. We needed the ability to unblock an end-user during a work stoppage situation.

One of the nifty features of AppLocker is that they have included several in-box PowerShell Cmdlets (in Windows 7 & Windows 2008 R2) that assist in AppLocker administration.  While these Cmdlets worked well, some of the early feedback from our helpdesk\support staff was that they wanted a GUI to assist them in identification and remediation.

With that request, AppLockerLet was born…

We chose the moniker of AppLockerLet, since it was GUI wrapper for AppLocker PowerShell Cmdlets. We wanted to create a GUI that helped the support staff with the following:

1.        Assist the helpdesk technician in quickly identifying a denied application and create a corresponding rule to allow the application to install\execute, removing the time spent in deciphering what kind of rule is needed and creating the rule to unblock the end-user’s work stoppage situation.

2.        You cannot easily elevate *and* run as a different user from a PowerShell context menu. Since only helpdesk technicians and other support staff have the ability to create local AppLocker rules, they need to launch PowerShell elevated and under their credentials.

The helpdesk technicians are local administrators on the end-users machines and commonly use Remote Assistance (running user the end-user’s context) to troubleshoot & diagnose issues.    

What AppLockerLet is and what it does.

Basically it reads from Event Viewer using Get-AppLockerFileInformation to determine which .exe, .dll, .msi or script has been blocked by policy.  It’ll then display the list of blocked applications within the UI, allowing the helpdesk or support personal to select and allow the executable or installer via the creation of a local AppLocker rule.

More to come in the next blog post…

Hello there,

I’m finally got around to starting up a blog…

I planning on using this blog to talk about a myriad of things that I find interesting or issues that I’ve encountered and how I’ve resolved them. Most of the articles that I write about will be tailored to System Center products, but Ill also sprinkle in topics on scripting, Group Policy and other “desktop management” type topics.

My hope is that someone somewhere will find useful information on the blog postings.

Cheers,

                -Ben