Archive for the ‘System Center’ Category

A problem recently encountered was causing major headaches. There was a runbook somewhere in the system that had an action running with the security credentials of a user that had left sometime ago. Their account had recently been disabled and the Orchestrator was logging thousands of errors and causing the Orchestrator database to grow at a massive rate. OBJECTINSTANCEDATA was growing at thousands of rows a second and hit 50 million rows and 16GB in size after only a few days.

(more…)

Each new update of ConfigMgr I will start a new entry for anything specific to that version I want to test or make notes of.

(more…)

Often if editing something like a Boot Image or Task Sequence and you experience a console crash, then next time you try to edit that object you may see a message saying it is currently locked for editing, giving only a choice to wait or open as Read-Only.

Some quick (unsupported) database edits can clear the lock, or there is a Powershell command that does the trick as well. The Powershell is a bit trickier, but is the “proper” supported method.

https://configmonkey.wordpress.com/2015/03/27/powershell-how-to-unlock-objects-in-sccm/

Powershell Unlock-CMObject: https://technet.microsoft.com/en-us/library/jj821915(v=sc.20).aspx

and more info on how SEDO works: http://blogs.technet.com/b/sudheesn/archive/2012/10/28/sedo-serialized-editing-of-distributed-objects-configmgr-2012.aspx

 

I am starting work on now upgrading have upgraded our ConfigMgr2012 R2 hierarchies to the new “Configuration Manager with no more version numbers” build 1511. There are roughly 120+ site servers in the central hierarchy (across 2 CAS hierarchies), so hopefully things go well. For the most part things went quite well, no major issues at all.

I’ll keep this page to note any special gotchas that are outside the various step-by-step guides already out there, and also some easy quick link references.

(more…)

I recently experienced an issue with a very large number of ConfigMgr 2007 package updates (400) to a large number of sites (1700). It turns out there was already a distribution job that was “stuck” in the queue and when the large update went out it resulted in a massive backlog. The end result being there were over 1.3 million files in the Replication Manager inbox that just weren’t being processed, and the number was increasing.

The only option in this sort of situation is to stop the services, move the files out of the inbox, let normal inbox processing resume and then copy the files back in a block at a time. In this case doing this manually wasn’t an option due to the number of files, so I resorted to a quick script based on the one found here: https://tricksntreats.wordpress.com/2010/05/30/sccm-backlog-fighting/

(more…)

I first had this happen on just one of my servers. It was annoying and was causing massive numbers of WMI entries in the event logs each time it happened. I tried to just stop and disable the ConfigMgr client, but it would be “reactivated” again by something. Recently at a client site I found it happening an a large number… so time to investigate.

I checked there were no push jobs running, but there was *something* causing it to repeat. Some digging later and I finally found the reason.

There is a scheduled task created by CCMSETUP to retry if it isn’t able to install correctly on the first attempt. Under some circumstances, this task isn’t cleaned up and so the reinstall keeps happening

(more…)

When you need to change the location that you have been saving all your package source files, you will then need to update all the existing packages and applications to point to that new location.

(Note: See here to read what happens when you do update all your source locations)

This is fairly simple for Packages, but is a bit more complicated for Applications (more…)

A quick link for reference to what happens in Configuration Manager when all you change is an application or packages source path, but the file contents are still the same?

This is an important point to understand as it does NOT resend all the files back out to DP’s again. This means you can change where you keep your master software repository without having to worry about massive network impacts.

This blog post has an excellent explanation: http://blog.configmgrftw.com/content-distribution-myth/

While installing multiple new ConfigMgr 2012 Management Points I was seeing a non-specific failure with an error code of 1603. Much troubleshooting and any web searches later, I discovered that there were in fact three different issues across the different servers that all failed with the same uninformative error.

  1. HTTPS binding missing in IIS
  2. Old WMI information from previous CM2007 client
  3. BITS not installed correctly

This was really quite bizarre. When I had found the “solution” and tried applying it to other servers I found that they had a different issue, which led to a mix of all three of the above. The old WMI issue being the most prevalent.

(more…)

[Place holder post – FULL POST write up coming shortly]

https://social.technet.microsoft.com/Forums/en-US/3ac88d59-d1b5-4826-a44d-bb94bfd80f66/configmgr-2012-update-source-content-deleted?forum=configmanagergeneral#39c42c3c-d3af-4362-b097-09c022adc86b

An issue where some source folder content of Windows Update deployment packages is deleted for no apparent reason.

Currently waiting for a response from the Microsoft ConfigMgr Product team on if they feel this is an issue worthy of a product update or just a TechNet article warning of the impact

Summary: issues relating to Update deployment packages that are migrated between ConfigMgr hierarchies that share the same source folder location. Automated “orphan cleanup” process will delete content from the folder if one of the hierarchies doesn’t need it, even it the other one still does.