Author: lpmautomation

Trigger Configuration Manager Actions via WMIC

Trigger Configuration Manager Actions via WMIC

Quite often when working on Software Updating projects I am aiming to bring compliance up quite quickly inside a change windows and need to leverage the abilitly to quicken the agents poll for certain actions. Most of the common tasks can be placed in a program and deployed out to machines rather than initiating these steps manually.

An example of initiating a Software Update scan is below:

WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule “{00000000-0000-0000-0000-000000000113}” /NOINTERACTIVE

There are a number of additional triggers which can be interchanged into the above command.

{00000000-0000-0000-0000-000000000001} Hardware Inventory
{00000000-0000-0000-0000-000000000002} Software Inventory
{00000000-0000-0000-0000-000000000003} Discovery Inventory
{00000000-0000-0000-0000-000000000010} File Collection
{00000000-0000-0000-0000-000000000011} IDMIF Collection
{00000000-0000-0000-0000-000000000012} Client Machine Authentication
{00000000-0000-0000-0000-000000000021} Request Machine Assignments
{00000000-0000-0000-0000-000000000022} Evaluate Machine Policies
{00000000-0000-0000-0000-000000000023} Refresh Default MP Task
{00000000-0000-0000-0000-000000000024} LS (Location Service) Refresh Locations Task
{00000000-0000-0000-0000-000000000025} LS (Location Service) Timeout Refresh Task
{00000000-0000-0000-0000-000000000026} Policy Agent Request Assignment (User)
{00000000-0000-0000-0000-000000000027} Policy Agent Evaluate Assignment (User)
{00000000-0000-0000-0000-000000000031} Software Metering Generating Usage Report
{00000000-0000-0000-0000-000000000032} Source Update Message
{00000000-0000-0000-0000-000000000037} Clearing proxy settings cache
{00000000-0000-0000-0000-000000000040} Machine Policy Agent Cleanup
{00000000-0000-0000-0000-000000000041} User Policy Agent Cleanup
{00000000-0000-0000-0000-000000000042} Policy Agent Validate Machine Policy / Assignment
{00000000-0000-0000-0000-000000000043} Policy Agent Validate User Policy / Assignment
{00000000-0000-0000-0000-000000000051} Retrying/Refreshing certificates in AD on MP
{00000000-0000-0000-0000-000000000061} Peer DP Status reporting
{00000000-0000-0000-0000-000000000062} Peer DP Pending package check schedule
{00000000-0000-0000-0000-000000000063} SUM Updates install schedule
{00000000-0000-0000-0000-000000000071} NAP action
{00000000-0000-0000-0000-000000000101} Hardware Inventory Collection Cycle
{00000000-0000-0000-0000-000000000102} Software Inventory Collection Cycle
{00000000-0000-0000-0000-000000000103} Discovery Data Collection Cycle
{00000000-0000-0000-0000-000000000104} File Collection Cycle
{00000000-0000-0000-0000-000000000105} IDMIF Collection Cycle
{00000000-0000-0000-0000-000000000106} Software Metering Usage Report Cycle
{00000000-0000-0000-0000-000000000107} Windows Installer Source List Update Cycle
{00000000-0000-0000-0000-000000000108} Software Updates Assignments Evaluation Cycle
{00000000-0000-0000-0000-000000000109} Branch Distribution Point Maintenance Task
{00000000-0000-0000-0000-000000000110} DCM policy
{00000000-0000-0000-0000-000000000111} Send Unsent State Message
{00000000-0000-0000-0000-000000000112} State System policy cache cleanout
{00000000-0000-0000-0000-000000000113} Scan by Update Source
{00000000-0000-0000-0000-000000000114} Update Store Policy
{00000000-0000-0000-0000-000000000115} State system policy bulk send high
{00000000-0000-0000-0000-000000000116} State system policy bulk send low
{00000000-0000-0000-0000-000000000120} AMT Status Check Policy
{00000000-0000-0000-0000-000000000121} Application manager policy action
{00000000-0000-0000-0000-000000000122} Application manager user policy action
{00000000-0000-0000-0000-000000000123} Application manager global evaluation action
{00000000-0000-0000-0000-000000000131} Power management start summarizer
{00000000-0000-0000-0000-000000000221} Endpoint deployment reevaluate
{00000000-0000-0000-0000-000000000222} Endpoint AM policy reevaluate
{00000000-0000-0000-0000-000000000223} External event detection

These can be placed in a program and deployed to your clients.

Ping Multiple Clients with Powershell

Ping Multiple Clients with Powershell

I am sure there are a 100 of these posts out there but my angle on this as always comes from a System Center Perspective!

Patch Compliance and acheiveing the holy grail of +98% compliance can be a difficult task so you need all the tools in your armoury and this tool can often be invaluable to save trying to connect to each machine manually.

When I am down to my last bunch of non-compliant machines, I am first looking for ones online to determine why they are not compliant.

From a ConfigMgr report, export the list and get these into a simple .txt format list and save the file.

With you below powershell script (which can be adapted for location of file) you can quickly see what clients are online for you to continue your troubleshooting exercise.

Below is an example:

Folder Created – C:\PowershellPing
File Created – C:\PowershellPing\Systems.txt (Contains List of Systems)

Create and save the following script as a .ps1 file

**Code Start***
$ServerName = Get-Content “C:\PowershellPing\Systems.txt”

foreach ($Server in $ServerName) {

if (test-Connection -ComputerName $Server -Count 2 -Quiet ) {

“$Server Host is Up ”

} else

{“$Server Host Not Reachable”

}

}
***Code End***

From a powershell Window execute the following command:

*Note – This is my example file locations depend on what you setup

cd to the directory.

.\PingSystems.ps1 | Out-File -FilePath C:\PowershellPing\PingResults.txt -append

This will output a file like below:

ping

ConfigMgr Admins Beware of KB2918614!!!!

ConfigMgr Admins Beware of KB2918614!!!!

After spending a large portion of the last two days troubleshooting some MSI installations while I continue to teach myself Software Packaging in the right way!, I came across a number of my MSI’s which were simply not running Active Setups correctly. They seem to not put in HKCU which when run in GUI were producing an error message:

Error 123: The filename, directory name or volume label syntax is incorrect.

Error123Hash

When this was logged out with MSI Verbose logging, the options I was using were msiexec /fup also produced an error complaining about SECREPAIR Hash Issues pulling down from the ConfigMgr DP. This behaviour was also witnessed when running a repair from Add/Remove Programs.

After spending alot of time looking at my 2012 Environment which I have built at least 20 times for different clients it turns out that in August 2014, Microsoft released an update for Windows Installer which has a known issue for how it handles Secrepair CryptAcquire for MSI’s. The result of this update is the impact talked about in this article.

By removing this update (KB2918614) all of my MSI repairs returned to their normal working state of referencing the locations on ConfigMgr DP.

I am not sure how widespread the issue is as it was difficult to get any information on but after spending a considerable amount of time on this, if I can help anyone else something good will have come from this 🙂

Installing MSE on Server 2012

Installing MSE on Server 2012

If you have a Server 2012 Host not part of your LAB and you wish to have security essentials installed until you have ConfigMgr up and running this can be done as outlined below:

NOTE* – Microsoft Security Essentials is designed for Windows 7 and is not compatible (nor supported) on Windows Server 2012.

But if you insist, you might as well end-up installing it on your Windows Server 2012.
1.Download a copy of MSE from Microsoft
2.Right Click on the “mseinstall.exe”.
3.Click on Properties.
4.Click on the “Compatibility”-tab.
5.Locate the “Compatibility mode”-section.
6.Check “Run this program in compatibility mode for:”.
7.Select From the (now active) dropdown menu “Windows 7″.
8.Open a Command Prompt as Administrator.
9.cd to your Downloads folder (ie. cd C:\Users\%username%\Downloads).
10.Run “mseinstall /disableoslimit” and follow the installer prompts to install MSE on your Windows Server 2012.

WSUS Log Files

WSUS Log Files

So often when interviewing or working with colleagues I often hear the question:

‘What is the best log file to look in if Updates are not deploying via ConfigMgr to clients????’

Well the answer is there is not just one. A number of log files work together to reflect the process of updates deploying and a few key ones I use are below:

Wsyncmgr.log
WUAHandler.log
Wsusctrl.log
WCM.log

Along with

Datatransfer.log
CAS.log

Often the issue will lie somewhere within these logs if the issues is specific to update deployment.

There is still the standard windowsupdate.log but I find the above are more granular where the issue lies if a problem was to occur!

Windows Server 2012 – Switch between Core and GUI

Windows Server 2012 – Switch between Core and GUI

Now in Windows Server 2012 there is no longer a one time decision to be made when you perform the installation of which GUI type you wish to imprint on the server.

This can be changed in using DISM with the following command.

Dism /online /enable-feature /featurename:ServerCore-FullServer /featurename:Server-Gui-Shell /featurename:Server-Gui-Mgmt

Microsoft SQL Servername does not match computer name

Microsoft SQL Servername does not match computer name

Anyone who has downloaded any of the Microsoft Hydration kits of late looking to import them into their own lab especially in my case as SQL 2008 is becoming harder and harder to get hold of nowadays may of stumbled over just what I did today.

By renaming the machine and joining to my lab domain generated a warning in OpsMgr pre-req as machine name was different to when SQL was installed.

Quickly resolved in management studio by the following:

 

Confirm current name – select @@ServerName

 

Then execute the following statements.

Run Query from the SQL query window one statement at a time

sp_dropserver ‘old_server_name’
sp_addserver ‘new_server_name’, ‘local’

My Server required a reboot to pick up the changes!

Report Server DB SQL Server Error Log 9002 – ConfigMgr 2012

Report Server DB SQL Server Error Log 9002 – ConfigMgr 2012

Working at a client site this week after retuning for a health check I noticed that the SQL Server Log drive for SRS had consumed almost all of the disk available at 30GB!!!

Now as we know the logs for SRS should not be anywhere near that and trying to shrink down the available space proved fruitless as SQL was complaining about the disk being full. The auto grow was configured to consume all disk so this could not be amended easily.

As an Interim measure the recovery model on the database was set to Full which once changed to Simple allowed the database shrink to be implemented and corrected thus preventing SQL from consuming all of the disk.

Now the auto grow can be amended and if required recovery model reverted back to full.

 

Theme: Overlay by Kaira LPM Automation LTD
London, United Kingdom