Month: October 2012
An added feature to ConfigMgr 2012 is the ability to directly deploy software updates without them being a deployment group. This can result in a “gotcha” moment when update are incidentally deployed to systems. This situation occurred to me recently when IE9 was deployed to a collection (fortunately non-mandatory!) but I could not find that update in any deployment group. If it has been deployed as part of many updates, then this would have never occurred and I could have easily removed the update.
The way to get yourself into this predicament is by doing the following. Note: this is just a lesson, don’t actually do this in production!
- In the console, navigate to Software Library > Software Updates > All Software Updates
- Select a single updates to install
- Select “Deploy” on the wunderbar
- Note that in the first page of the wizard, it LOOKS like you’re adding updates into a software update group.
- Finish the wizard with whatever settings (please don’t make this a Required install, lest you screw yourself)
Now go into node Software Update Groups. Where is the deployment group that was supposed just created? It isn’t there!! To then delete the deployment, find an individual update, go to the Deployment “tab” and delete the deployment. Note how the update group says “Individual”
To prevent this from accidentally occurring to you, a general rule of thumb is to add the update(s) to be installed into a new or existing Software Update Group and then deploy that group to a collection.
I was in a recent situation where I needed to create an install package for First Data’s FirstDispute client, but to eliminate the shortcuts. It could have been easy to just install the software and then delete the shortcuts with a script, but instead I decided to dig around into the MSI with Microsoft Orca. Within the MSI properties I found table “Shortcut” and items Client_Desktop, Tracking_System_Desktop, and HostReportSystem_Desktop. By simply “dropping” these items and then saving this as a transform, I was then able to deploy the software along with the TRANSFORMS property to eliminate the desktop shortcuts.
To do this on your own:
- Download and install Orca (available in any Windows SDK)
- Open Orca
- Go to File > Open. Browse to and open the MSI file for the FirstDispute client
- Find Table “shortcuts”
- Right-click each shortcut to be removed and select “drop row”
- Save the file as a new transform (.mst) file as NoDesktopShortcuts.mst
- Run the install as FirstDisputClient.msi TRANSFORMS=NoDesktopShortcuts.mst
This is the wildest thing I’ve ever seen. My client was describing to me the problem, but I had a hard time believing them until I could see it reproduced for myself. When attempting to add direct memberships to a collection, sometimes it only shows returns a subset of the limiting collection and not the full list. I have found out that this is indeed a known bug/case that is open with the ConfigMgr development team.
When using the direct rule wizard and using a mouse with clicks, it only makes a handful of resources available from the limiting collection.
Then when repeating the steps but using the only a keyboard and buttons, all 1000+ systems became available.
The limiting “parent” collection was a created in a unique way that is new to ConfigMgr 2012. Of that collection, it’s limited to All Systems, but the memberships rules is using the new “include collections”.
What made this “funny” at my client is that literally every time I did a direct membership, it worked for me….and every time the client did it, it failed. We all couldn’t help but laugh because they thought I was somehow messing with them.
A best practice in ConfigMgr 2007 was to have remote distribution points “protected” so that client in other subnets would not incidentally download content from them. This was particularly important for DPs that were slow WAN links. In ConfigMgr 2012 however, having a protected DP looks different. Instead of the old checkbox on the DP settings, now you add the Boundary (IP address range/subnets or AD Sites) into it’s own Boundary Group. In this way only clients in that subnet will pull from that DP.
When attempting to set up and configure the ConfigMgr 2012 site system role for reporting services, a frequently experienced “problem” is that the instance name can be blank/empty in the wizard and thereby unable to proceed with the wizard. This usually occurs when SRS has not been pre-configured properly.
While it is common “knowledge” that the reporting services database needs to be created first, an oft-overlooked step is to use the Reporting Services Configuration Manager to create the virtual directories for IIS. And it is these steps which need to be completed to get you on your way.
- Open Reporting Services Configuration Manager
- Connect to the server/instance
- Click on Web Service URL – make a fake change, such as changing the name of the virtual directory and then putting it back to ReportServer – and clicking Apply. This will then create the new virtual directories.
- Click on Report Manager URL – again, make a change to the name and put back to just Reports – and click Apply to generate the new virtual directories.
- Close configuration manager
- Return to the CM12 site role setup program, click “Verify” for the database connection, and voila the instance is now populated correctly!
An issue that plagued many admins over the last couple of years is that download (and thus installation) when a task sequence installs many Software Updates would hang and/or be stuck on the first update (KB2509007). This was a problem relegated to CM07. However, I am experiencing the same ‘ol thing in my home lab environment. One resolution discussed for CM12 has been to 1) ensure the DP is set to allow anonymous connections, and 2) set the client install parameter SMSMP=FQDN.
However, these did not work for me in my lab and since no hotfix is available at this time, I’ve taken the quick workaround approach for my image build by using a VBScript to automate the installation of updates directly using the Windows Update Agent. While I cannot take credit for the below script, I did modify it to eliminate the prompt messages and automatically “accept” installation of updates. I just run this script as part of my task sequence via Run Command Line and it does the trick.
Download revised script: http://sdrv.ms/QT0F0S
When deploying a Win7 image, the below errors were received during the application installs of a few test applications. The catch is that the applications install without issue when the PC was NOT joined to the domain…but when it IS joined to the domain, the installs fail. I cannot locate any information online about this error code, so needed to post it here. Per Microsoft support:
According to my research, this error code is coming from the Microsoft Policy Platform and the error 0x80730c03 actually can be interpreted to “Failed to prioritize rules”. Actually, this issue has already been filed as an internal bug but yet no workaround/solution is available. Consider the current situation, if you feel it has big business impact and want to track the latest info of the progress of the solution, please submit a phone incident as this is out of Community boundary. And if that’s approved to be Microsoft product issue, you can ask for refund for the specific incident.
This sample info is from SMSTS.log – the error code is at the bottom in red.
Received job completion notification from DCM Agent
Policy Evaluation failed, hr=0x80730c03
Setting TSEnv variable ‘SMSTSAppPolicyEvaluationJobID__ScopeId_39406D81-9115-4158-A72F-FAEE3B45B510/Application_f2a0c5c5-23ce-42a0-8c2a-d5a3ce3ddaa6’=”
m_hResult, HRESULT=80730c03 (e:\nts_sccm_release\sms\client\osdeployment\installapplication\installapplication.cpp,993)
Step 2 out of 5 complete
Install application action failed: ‘Adobe Flash Player 11.4.402.278 ActiveX’. Error Code 0x80730c03
Sending error status message
Setting URL = http://servername.domain.com, Ports = 80,443, CRL = false
Setting Server Certificates.