This blog is owned and operated by the ANZ ConfigMgr Premier Field Engineer team.
Contributors
Ian BartlettMatt ShadboltGeorge Smpyrakis
Heaps of PFE’s speaking at this years TechEd Australia!
Ian Bartlett & Mohnish Chaturvedi – Microsoft Application Virtualization 5.0 Introduction (Wed 12 Sep, 9:45-11:00)
Grant Holliday – From Server to Service: How Microsoft Moved Team Foundation to Azure (Thu 13 Sep, 11:30-12:45)
Matt Shadbolt & George Smpyrakis – Implementing SCM for Compliance in SCCM 2012 (Thu 13, 1:45-3:00)
Alex Pubanz & Jesse Suna – Kick Starting your Migration to Windows Server 2012 (Friday 14 Sep, 8:15-9:30)
Chad Duffy & Tristan Kington – DirectAccess: Your Next Gen Remote Access Experience (Fri 14 Sep, 11:30-12:45)
Shyam Narayan – Application Hosting Models in SharePoint 2013 (Fri Sept 14, 11:30-12:45)
In ConfigMgr 2007 we had a registry key called CacheExpire which would allow a client to start a new PXE session after 60 minutes. The idea is, if a build is mandatory the cache will hold onto the session to ensure it doesn’t get into a rebuild loop.
It was a bit of a pain when you were developing/testing your OSD builds because if it failed, you had to wait for the cache to run out or clear it manually. So many engineers would change the key to 120 seconds or so.
HKLM\Software\Microsoft\SMS\PXE\ CacheExpire=120
I’ve recently been testing a new build in ConfigMgr 2012 using PXE as my boot method, and went in search of the CacheExpire value to speed up the process, and found its no longer there. In fact, the entire PXE key is missing.
The reason is quite simple, in ConfigMgr 2012 the PXE Service Point is no longer a separate role – it’s now integrated with the Distribution Point role. So I checked in the DP registry key for a CacheExpire… no luck.
HKLM\Software\Microsoft\SMS\DP
So I decided to try and create one and see how it went… bingo, my PXE Cache is now 120 seconds.
Fox the lazy, here’s the exported key & value
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\DP] "CacheExpire"="120"
Matt Shadbolt
Your ConfigMgrDogs team will be speaking at TechEd Australia 2012!
Come and check out our sessions & buy us a beer!
Matt Shadbolt and George Smpyrakis – Configuration Manager 2012 and Security Compliance Manager
Ian Bartlett and Mohnish Chaturvedi – Introduction to App-V 5.0
Session time and room information will be posted shortly.
ConfigMgr hardware inventory is a very important and widely used feature. We use it to collect all sorts of information, from hardware info such as disk configuration, amount of RAM, etc. Hardware Inventory is also used to query the Add/Remove Programs to see what software is installed on a machine.
All hardware being queried by default can be found in your SMS_Def.mof file (%ConfigMgrInstallDir%\Inboxes\clifiles.src\hinv). There are heaps of WMI classes that are enabled by default – and even more than you manually need to enable. But sometimes we need to collect hardware information for a non-standard piece of hardware, or a device that isn’t included in the SMS_DEF.mof file.
To cater for this type of inventory, we provide a function to extend the classes using special files call IDMIFS and NOIDMIFS.
Creating custom Hardware Inventory classes
By default the IDMIF/NOIDMIFS collection is not enabled, but to enable it open your Hardware Inventory Client Agent and tick the MIF collection boxes.
There's an interesting warning here – Enabling these settings increases your security risk by permitting ConfigMgr to collect and process unvalidated client data.
IDMIFS/NOIDMIFS are unlike the SMS_DEF.mof file as they are unvalidated. This means they aren’t checked against any standard and can contain pretty much anything. The problem with this is, any user who is a local administrator on their machine, can add a NOIDMIF file to their CCM directory, and ConfigMgr will process this directly into the database and create custom tables. While this isn’t a huge problem, it would not be hard for a rouge user to create hundreds or thousands of extra tables in your ConfigMgr database.
In my demo, I’m going to create a custom Hardware Inventory class called Wide World Asset Numbers. A company could use this class as a way to track asset numbers of their clients.
First of all, from one of my clients I’m going to browse to %Windir%\System32\CCM\Inventory\Noidmifs
To create this class, we create a text file in the Noidmifs directory, give it a relevant name (addclass1.mif) and insert something like this:
Start Component Name = "System Information" Start Group Name = "Wide World Asset Numbers" ID = 1 Class = "wideWorldAssetNumbers" Key = 1 Start Attribute Name = "Computer Asset Number" ID = 1 Type = String(10) Value = "414207" End Attribute End Group End Component
This would create a class called wideWorldAssetNumbers in your Hardware Inventory. For more info, see http://technet.microsoft.com/en-us/library/cc181210
If I now run a Hardware Inventory on the client I’ll see in the InventoryAgent.log that it was processed (I’m running this on a Site Server by the way, that's why the path is SMS_CCM\Inventory)
And if I check the hardware inventory on the client, I’ll now see a new class called Wide World Asset Numbers
You can also see a new table in the ConfigMgr database
And that’s how easy it is to create a new Hardware Inventory class, and a new ConfigMgr database table!
The Product Group have recently announced the Beta of ConfigMgr 2012 SP1 at TechNet 2012 North America.
You can view the announcement at http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/MGT309
Enhancements include:
So I posted this on my mattlog.net blog ages ago, but for some reason it didn’t make the migration over to our new Technet ConfigMgrDogs blog, so thought I should repost as a new entry.
I still find it staggering how many customers I visit who had no idea about these features!
One of the more important but commonly missed features is the Error Lookup option in Trace32’s Tools > Error Lookup (Ctrl + L) menu.
The Error Lookup tool will return descriptions of cryptic error codes from
Windows error codes
WMI error codes
Winhttp error codes
When trying to troubleshoot specific issues such as site replication issues, it’s sometimes nessesary to open more than one log file at once. Windows 7’s window snap feature makes viewing two logs side-by-side really easy, but sometimes a more accurate timeline is needed between viewing log files.
If you select Open in Trace32, Ctrl-click on multiple log files in the open dialog box, tick Merge selected files you will find that all the selected log files will merge together into one large super log. The log entries are automatically sorted by time so it’s super easy to see ConfigMgr process certain things and log the progress across multiple logs.
In this quick example I’m just viewing the process for finding a clients default management point
As you can see, the client is logging to both LocationServices.log and ClientLocation.log and it’s quite easy to read the timeline of what is going on.
Lastly, a minor but handy tip, Trace32 by default will save the last log location that you opened. This is really handy as you don’t have to browse to the logs path every time you want to read SMS logs. It is a bit of a pain though when you use Trace32 on a client, because every time you launch Trace32 for the first time on a certain machine, it defaults to the %userprofile%\Desktop directory. The Last Directory registry found at HKCU\Software\Microsoft\Trace32 is the key that controls the default open location. If you add a GPO that updates your clients to %windir%\System32\CCM\Logs\ every time you jump on a machine it will automatically open Trace32 at the client log location.
With the new version of Configuration Manager, comes a bunch of new juicy logs. I’ll separate the posts into Client and Server. In this first instalment, I’ll cover off on the new logs found on your clients.
The first thing you need to know, is the log location has changed slightly.
Client logs can now be found at C:\Windows\CCM\Logs – rather than in the System32 or SysWoW64 directory
With the new ConfigMgr 2012 App Model, we now scan each machine at a regular period (default is every 7 days) and make sure that applications that should be installed on a machine are indeed installed. The AppDiscovery.log will show you the discovery engine (based on DCM) checking to make sure the app is installed.
Performing detection of app deployment type MS_Silverlight(ScopeId_73F3BB5E-5EDC-4928-87BD-4E75EB4BBC34/DeploymentType_246b2460-f182-4916-959c-0a2c41c55ca0, revision 2) for system. AppDiscovery 3/05/2012 9:27:30 AM 7988 (0x1F34)
+++ Application not discovered. [AppDT Id: ScopeId_73F3BB5E-5EDC-4928-87BD-4E75EB4BBC34/DeploymentType_246b2460-f182-4916-959c-0a2c41c55ca0, Revision: 2] AppDiscovery 3/05/2012 9:27:31 AM 7988 (0x1F34)
Here we can see the WMI query for the Microsoft Silverlight application and it not being found. The AppDiscovery.log will then flag Silverlight for installation
ActionType - Install will use Content Id: Content_b0e86929-a5f2-4154-b876-ed83965ce25d + Content Version: 1 for AppDT "MS_Silverlight" [ScopeId_73F3BB5E-5EDC-4928-87BD-4E75EB4BBC34/DeploymentType_246b2460-f182-4916-959c-0a2c41c55ca0], Revision - 2 AppDiscovery 3/05/2012 9:27:34 AM 12156 (0x2F7C)
If an application should be installed, and the AppDiscovery doesn’t find it, the AppEnforce log should kick in with the installation routine +++ Starting Install enforcement for App DT "MS_Silverlight" ApplicationDeliveryType - ScopeId_73F3BB5E-5EDC-4928-87BD-4E75EB4BBC34/DeploymentType_246b2460-f182-4916-959c-0a2c41c55ca0, Revision - 2, ContentPath - C:\Windows\ccmcache\1a, Execution Context - SystemAppEnforce 3/05/2012 9:28:29 AM 7988 (0x1F34)
A user is logged on to the system. AppEnforce 3/05/2012 9:28:29 AM 7988 (0x1F34)
Performing detection of app deployment type MS_Silverlight(ScopeId_73F3BB5E-5EDC-4928-87BD-4E75EB4BBC34/DeploymentType_246b2460-f182-4916-959c-0a2c41c55ca0, revision 2) for system. AppEnforce 3/05/2012 9:28:29 AM 7988 (0x1F34)
+++ Application not discovered. [AppDT Id: ScopeId_73F3BB5E-5EDC-4928-87BD-4E75EB4BBC34/DeploymentType_246b2460-f182-4916-959c-0a2c41c55ca0, Revision: 2] AppEnforce 3/05/2012 9:28:29 AM 7988 (0x1F34)
App enforcement environment:
Context: Machine
Command line: "Silverlight.exe" /q
Allow user interaction: No
UI mode: 1
User token: null
Session Id: 4294967295
Content path: C:\Windows\ccmcache\1a
Working directory: AppEnforce 3/05/2012 9:28:29 AM 7988 (0x1F34)
Prepared working directory: C:\Windows\ccmcache\1a AppEnforce 3/05/2012 9:28:29 AM 7988 (0x1F34)
Prepared command line: "C:\Windows\ccmcache\1a\Silverlight.exe" /q AppEnforce 3/05/2012 9:28:33 AM 7988 (0x1F34)
Executing Command line: "C:\Windows\ccmcache\1a\Silverlight.exe" /q with system context AppEnforce 3/05/2012 9:28:33 AM 7988 (0x1F34)
Once the application has installed, it will rerun the application detection and this time succeed.
+++ Discovered application [AppDT Id: ScopeId_73F3BB5E-5EDC-4928-87BD-4E75EB4BBC34/DeploymentType_246b2460-f182-4916-959c-0a2c41c55ca0, Revision: 2] AppEnforce 3/05/2012 9:29:41 AM 7988 (0x1F34)
The AppInterval.log works with the two previous logs, and should tell you which applications are required. You should see something like
ScopeId_73F3BB5E-5EDC-4928-87BD-4E75EB4BBC34/DeploymentType_246b2460-f182-4916-959c-0a2c41c55ca0/2 :- Current State = Installed, Applicability = Applicable, ResolvedState = Installed, Title = MS_Silverlight
The CCMVDIProvider.log will show you if the machine is a virtual or a physical machine
The EndpointProtectionAgent.log will only show you that the SCEP agent is/isn’t installed. It will not show you any information about definition updates. For SCEP definition updates and SCEP functionality, you’ll find a bunch of logs in C:\ProgramData\Microsoft\Microsoft Antimalware\Support
ExpressionSolver.log is a log that records MSI discovery. This log is only available when verbose logging is enabled
The ExternalEventAgent shows all of the state messages sent from SCEP, into the CCM client. The CCM client will then process this state message as it would any internal state message.
This log file records all Software Inventory file system scans. You can see in the log file below, that we’re looking for qmgr.dll, scrnsave.exe, scrnsave.scr and msiexec in the System32 directory.
Query = SELECT __class, __path, __relpath, name, path, lastwritedate, size, companyname, productname, productversion, productlanguage, fileversion, filedescription FROM FileSystemFile WHERE name = 'qmgr.dll|scrnsave.exe|scrnsave.scr|msiexec.exe' and path = '%windir%\\system32\\*' and iscompressed = false and isencrypted = false; Timeout = 14400 secs; ScanInterval = 2 msecs; SkipFile = skpswi.dat
You’ll see a bunch of SCNotify logs in your logs directory. This log describes the user notification for new applications. In the log you’ll see a bunch of WMI calls, and whether or not applications should notify the user of their availability
This software should not display a user notification balloon, removing it from the available notification list.
The SoftwareCatalogUpdateEndpoint log will show any changes to the Software Catalog URL and will show the URL being added to the Trusted Sites list in Internet Explorer
CSoftwareCatalogUpdateHandler::StartUpdateTrustedSitesProcess: Started UpdateTrustedSites process CSoftwareCatalogUpdateHandler::SetCatalogSecurity: Updating the registry for Software Catalog.
This log will show you the Software Center notifications and whether or not the Software Center is installed and healthy.
The UpdateTrustedSites logs the actual updates after the SoftwareCatalogUpdateEndpoint reports that the URL needs to be added to the Trusted Sites
CSoftwareCatalogUpdateHandler::AddDefaultPortalToTrustedSites: Catalog Url should be added to the trusted sites zone. UpdateTrustedSites 18/05/2012 1:13:32 PM 14172 (0x375C)
AddDefaultPortalToTrustedSites: url = http://applicationcatalog.yourdomain.com:80, zone = 258 UpdateTrustedSites 18/05/2012 1:13:32 PM 14172 (0x375C)
With the new 2012 App Model, we need to determine which users are primary users of a device. The UserAffinity log will show which users have been added as primary users, and the method for determining the primary user
Auto affinity threshold settings Days = '21', User Minutes = '2880', AutoApproveAffinity = '1'. UserAffinity 18/05/2012 1:12:33 PM 14332 (0x37FC)
No WMI instance. Setting an affinity. UserAffinity 18/05/2012 1:12:45 PM 14332 (0x37FC)
Setting auto affinity for user 'yourdomain\mattshadbolt'. UserAffinity 18/05/2012 1:12:45 PM 14332 (0x37FC)
Successfully sent user affinity state message for user ‘yourdomain\mattshadbolt'. UserAffinity 18/05/2012 1:12:45 PM 14332 (0x37FC)
Successfully saved user affinity data for user ‘yourdomain\mattshadbolt' into WMI. UserAffinity 18/05/2012 1:12:45 PM 14332 (0x37FC)
We can see that AutoApproveAffinity is enabled for any users that have used the machine for anyone using the machine within 21 days, and for 2880 minutes or more.
So that's it! If you find any other logs that weren’t around in 2007, please let me know and I’ll do my best to cover them!
A list of Knowledge Base Articles and Hotfix information for Configuration Manager 2012 has been published on the Technet Wiki.
This is a living document and will be updated regularly:
http://social.technet.microsoft.com/wiki/contents/articles/9539.list-of-public-microsoft-support-knowledge-base-kb-articles-for-system-center-2012-configuration-manager-configmgr-2012.aspx
I suggest subscribing to the RSS feed and checking it regularly. That way you’ll always have the most up-to-date information:
http://social.technet.microsoft.com/wiki/contents/articles/9539.list-of-public-microsoft-support-knowledge-base-kb-articles-for-system-center-2012-configuration-manager-configmgr-2012/rss.aspx
Note that these are only the publicly published KB articles and Hotfixes. If you’re having specific issues, please contact Premier Support and they can check if there is a private KB article or Hotfix available.
In CM12 we have a number of changes in Software Updates. One of the most anticipated one’s is Auto Deployment Rules.
Yes finally I hear you say….
Well Lets run through creating an Auto Deployment and one little gotcha to keep your eye on.
Software Library > Software Updates > Automatic Deployment Rules
Choose Create Automatic Deployment Rule from the Ribbon or Right click on the mouse.
In the first screen we can choose a Template
(Templates are no longer a node in the console they are now created when creating an Auto Deployment Rule or manually Deploying Updates and are saved at the Summary screen.Ill point this out later in the post)
You can Select to Add to an Existing Software Update Group or Create a new Software Update Group.
If you select Add to an Existing Software Update Group a brand new group will be created the first time the Auto Deployment Rule is run and every time the rule runs after that the new updates are added to that group.
(NOTE You cannot create a software Update group manually and then create an Auto Deployment rule to add new updates to that group. Even if you give it the same name and description the Auto Deployment Rule will still create a new group. See Figure below.The group created at 6:02 pm was done manually. I then ran the Auto Deployment rule at 6:07 pm and you can see that it creates a group with a duplicate name and description.)
If you select Create a new Software Update Group every time the rule is run a new Software Update Group is created.
You can also choose to Enable the deployment after the rule is run.
Here you can choose to use Wake on lan and also decide whether to automatically deploy all updates and approve any license agreements or deploy only updates that do not include license agreements.
This is where you select the requirements to select the updates to auto approve.
Here you can set a Schedule for the Rule to run. Potentially every Patch Tuesday or Daily for Forefront updates.
Or you can run the rule manually.
Similar to CM07 we can set the deployment schedule and whether the Deployment will be Mandatory.
Set the User Experience, deadline behaviour and reboot suppression.
We can now Generate Alerts if the compliance falls below a certain after a certain period of time. As before we can select to disable alerts for Operations Manager.
Set your Deployment options
Either select an existing package or create a new one for the new updates
Select a DP or DP Group
Where to download the updates from
Choose a language
On the Summary screen you can Choose to Save your settings as a Template for future use
We now see the new Rule in the console and we can choose to Run Now from the ribbon.
The log file for troubleshooting is Ruleengine.log
We can see the Auto Deployment Rule is kicked off
Evaluating and downloading updates
Here we see it looking for an existing update group and not finding one therefore creating a new Software Update Group then adding the updates to that Group.
Back to the console.If we select Software Update Groups we now see the newly created Windows 7 Automatic Deployment and the Deployment (Yet to be enabled) on the tab below.
When we select Show Members we can see the updates applied.
and there you have it.
The ConfigMgr 2012 Package Conversion Manager (PCM) tool allows administrators to convert their legacy SCCM 2007 packages and programs into the new ConfigMgr 2012 Application and Deployment Types. This applies for all legacy packages apart from virtual APP-V packages that will automatically be converted to the new application model during the migration process. Once your legacy packages have been migrated and you have installed the Package Conversion Manager utility, then it is just a matter of analysing your packages in order to determine which readiness state it is in, and then converting your packages.
There are still a number of bugs in the RTM version of the PCM tool but all in all it works well.
It is worth noting that any legacy packages that have been configured to run another program first will only create the CM2012 Application Dependency if the program is in a different source Package ID. IE. “ Package with program dependent upon another program in the SAME package will not have that dependency converted” (from TechNet). To get around this you can just manually create the dependencies once you have converted your packages to Applications.
For this demonstration I am using an Adobe Reader X Package/Program with Package ID CEN0001A
We need to Analyse a package to determine whether our package is in an appropriate state to be migrated to the new Application model or whether some remediation work will be required to prepare the package to be converted to an Application and more importantly into a Deployment Type.
Expect to see either results after you have analysed your legacy package:
1. Automatic – Your package is in a state that will allow for a successful migration to an Application
2. Manual – Some remediation work on your legacy package is required before it can be successfully migrated to an Application Deployment Type.
Once the analysis is done you will see the readiness state under the Summary tab of your Package
If your legacy package returns an Automatic readiness state, than you can simply select the Convert Package option (This option will be GREYED out if Automatic is not returned) to convert your package to an Application.
If your legacy package returns a Manual readiness state, than some work needs to be done to fix some issues before you can convert it to a CM 2012 Application.
So we can see that my Adobe Reader package is not quite ready to be converted to a CM 2012 Application due to the Readiness state indicating Manual and the issue provided is because no Detection Method has been defined.
NOTE: Application Detection Methods are mandatory for any CM 2012 Application so expect this as a common issue.
So how do we fix this issue so my Adobe Reader package can be converted to a Application??? We use the Fix & Convert Tool to add the required information.
Wizard Screen Shots…
THATS IT, WE’RE DONE!!
So if we now have a look under Applications we will see that we have an Adobe Reader X Application with a Deployment Type created for us.
AS SIMPLE AS THAT… GOOD LUCK!!