Global conditions in ConfigMgr 2012
One of the very need features in the new Application model is Global conditions. A Global condition is a requirement rule that is evaluated in real time by the client. The client will only start downloading the application if the global condition is true.
ConfigMgr. 2012 ships with several global conditions like memory, operating system, primary user etc. Those conditions are pretty useful and can be used right out of the box.
Besides the canned conditions, creating custom conditions can be very powerful and all you need is a few steps to get your started. In this post, I’ll explain how you can create a global condition based on WMI that can be used when deploying applications to specific hardware models. For the sake of testing I have created an Application that must only be installed on all Lenovo W510 laptops.
Creating a WMI condition
My global condition will query WMI prior to downloading the application and verify that the computer model matches a Lenovo W510. In order to figure out which WMI class to use, I have downloaded Scriptomatic from Microsoft.
When selecting the Win32_computerSystem class I can see that the property I’m looking for is “Model”.
1. Next is creating the condition, open the ConfigMgr. administrator console, select Software Library, Application Management, Global Conditions and click Create Global Condition from the ribbon.
Create a condition with these settings:
Name: Computer model
Device type: Windows
Condition type: Setting
Setting Type: WQL query
Name space: root\cimv2
Configuring the application to use the global condition
1. Select the Application - in my example 7-ZIP and open the deployment type properties.
2. Click Requirements
Click Add and configure these settings
Condition: Computer model
Rule type: Value
Value: 431929G (that’s the computer model name found with Scriptomatic)
1. Click OK and save the changes.
Testing the global condition
Prior to installing the application, I will create a simulated deployment and use that to verify if my global condition is working.
Right click the Application and select Simulate Deployment.
Select a target collection, the Install action and finish the deployment
A simulated deployment is almost a real deployment except that the user will never notice anything and that the application is never installed. All the dependencies and requirements rule are checked.
Open the Monitoring workspace, select deployments and have a look at the results from the simulated deployment.
Click View Status to get more information about the simulation.
Click Requirements Not Met. Notice that is show the Actual Value of the WMI property, very nice
Getting ready for Windows 8
By Johan Arwidmark
Chief Technical Architect – Knowledge Factory
On February 29 Microsoft will be releasing the Consumer Preview of Windows 8, and at TechEd in June, both TechEd North America and TechEd Europe, you will be able to attend to a whole bunch of sessions related to Windows 8. This also means that the time for start learning about Windows 8 is now, so I decided to put together a few good resources for you.
Building Windows 8 - An inside look from the Windows engineering team
The Windows 8 Roadshow – If you are lucky to live in Sweden: An expert team of six serious geeks (me included) is touring the country in late march.
1 hour video session - Inside Windows 8 – Creating Custom WinPE 4.0 boot images
1 hour video session - Inside Windows 8 – The new Assessment and Deployment Kit, ADK
1 hour video session - Inside Windows 8 – Mastering the Setup Engine
Resource Pools in Operations Manager 2012 (SCOM)
Today with the current version of SCOM, we have problems with failover on the management server side when we talk about Network device or Linux/UNIX agent. A normal Windows Agent will automatically fail over to another Manage Server but since it’s the Management Server who initiate the session against a Network Device or Linux/UNIX host it’s not possible to do a automatically fail-over.
In 2012 the solution is: Resource Pool – A Resource Pool is a collection of Management Severs which together will decide a primary management server for the agent, and are able to switch over to another management server in case of a management server error. Beside the management servers you are able to include an Observer server so it’s like a failover cluster. SCOM 2012 must always have 2 Management Servers and one Observer, or three management servers in a Resource pool to be able to vote for a primary management server for an Agent.
PowerShell Commands for the Resource Pool :
Information about Resource Pool:
Get-SCOMResourcePool | FT (Check the fields: IsDynamic and Observers.)
Creating a new Resource Pool:
$PoolMembers = Get-SCOMManagementServer
New-SCOMResourcePool –DisplayName “Cisco Pool” –Member $PoolMembers –Passthru
Add a server called CTIIS as an Observer of the Cisco Pool, Type:
$Obs = GET-SCOMAgent –Name “CTIIS.hq.com”
GET-SCOMResourcePool –DisplayName “Cisco Pool” | SET-SCOMResourcePool –Observer $Obs
GET-SCOMResourcePool –DisplayName “Cisco Pool”
Extending OSD progress UI Info in SCCM
While running a task sequence, info on what is happening is shown in the progress UI, well the name of the Task Sequence, and the step that is running anyway!!
But what if we could extend that info to let us know other things as well! Turns out that is as easy as typing a little extra text in the Task Sequence editor.
Let say you are administrating a large environment, doing several OSD tests against a number of MPs, and DPs. Now wouldn’t it be nice if we could actually see where data is picked up, right there on the screen during deployment.
Let go with the location of the OS image, which you would always want to pick up from the local DP!
First navigate to you image in the Operating System Images node in SCCM, and check the Image ID, here CEN00009
Open your Task Sequence, in edit mode. Highlight your Apply Operating System step, and change the name to include the OS image location variable %_SMSTSCEN00009%
That’s all there is to it. When you now run your TS the content of the variable shown in the progress UI like this
Same scenario as before, but now we would like to know which MP the client is installed against. In this case we just need to change the name of the “Setup windows and ConfigMgr” step to include the variable &_SMSTSMP% like this:
This again would show this:
The only thing you need now is a list of all the available variables. To get that, just run the following .vbs script, and all variables will be added to SMSTS.log
Set Env = CreateObject("Microsoft.SMS.TSEnvironment")
For Each Var In Env.GetVariables
WScript.Echo Var & "=" & Env(Var)