When running Configuration Manager current branch 1606 you might run into a situation where you cannot modify the language configuration of a site. The option is simply greyed out, preventing you from adding any client or server languages.
The reason to why this is happening can be found in the ConfigMgrSetupWizard.log (hat tip to fellow MVP Roger Zander for pointing this out). Here we see an entry indicating that setup detected that client piloting is enabled for the site and as a result the modify language configuration option will be disabled.
So if we want to make any language modifications we need to promote the pre-production client to production first. This can be done in the administration workspace in the updates and servicing node.
Once the previous step is completed we can run the Setup Wizard again and in Site Maintenance the modify language configuration option is no longer greyed out. Adding client and server languages is possible.
Conclusion: you cannot change the language settings as long as the pre-production package has not been promoted.
The underlying reason for this is that we cannot apply language pack MSP files for the newer client to an older client version. When in piloting mode the new binaries have been updated everywhere, except for the client folder for production. Adding new client language packs would copy the newer language pack MSP files from cd.latest to the client folder that still has an older client version. These language pack files are not compatible with that older client – and as a result would be deleted.
Hope it helps!
A customer that recently upgraded to Configuration Manager 1511 CB ran into an issue with deploying newly captured OS images. The task sequence is hanging on client initialization and fails eventually. Images captured before the upgrade could still be deployed without any issues.
This blog post details how we resolved this.
When deploying an OS image captured using a Build and Capture task sequence in Configuration Manager 1511 the client hangs on the client initialization step. In the smsts.log we see an entry Waiting for the CCMExec service to be fully operational . After that there is one more entry referring to loading TSRES.DLL .
This is a known bug in Configuration Manager 1511 which is logged on Connect (ID 2153746).
Feedback on the connect item indicates this will be fixed in an upcoming update to the Configuration Manager current branch. The workaround for now is to not include the client in the image.
Note : in 1602 Technical Preview this issue has already been fixed.
There is another way to work around this if you do not want to pursue the alternative not to include the client in the image.
For this you would need to modify the Build and Capture task sequence to include two additional steps:
- Step 1 : run ccmrepair
- Step 2 : reboot the system
- An example is shown in the screenshot below.
When deploying the newly captured image using the modified task sequence the client will no longer hang on initializing.
Once the next update of Configuraiton Manager CB is implemented in your environment these two steps can be removed again.
Hope it helps!
ConfigMgr R2 SP1 upgrade does not clean up previous Cumulative Update entries in Control Panel > Programs and Features
Just a quick blog post on a small anomaly with Configuration Manager R2 Service Pack 1.
When upgrading an existing Configuration Manager site it seems the Installed Updates entries related to prior Cumulative Updates are not properly cleaned up. After upgrading a site the end result for Installed Updates looks like this:
The above example is based on a site that was up to Cumulative Update 5 – but the same happens with earlier released Cumulative Updates.
Although this is not really an issue and more cosmetics, it is something that could have been handled more properly by the Service Pack installer. A scenario where this potentially may cause unwanted effects is when using this information in your queries (collections, etc.).
The entries displayed are read from the registry. The screenshot below shows the entry in the registry for the particular cumulative update:
I used the following steps to clean this up:
- Start the Registry Editor (regedit.exe)
- Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall .
- Locate the key for CU5 (see screenshot) and take a backup (right-click > export).
- Delete the key for CU5.
- All done – the entry is no longer displayed.
Note that this cleans up the cosmetics part only – any other leftovers (if any) from Cumulative Updates (and alike) will still remain on the system.
Until next time!
Last week Kim blogged about an issue with Windows 7 and Software Updates that some of his customers had been reporting.
Kim had already outlined the issue and the symptoms, plus also provided a few workarounds which may help in resolving it. Through this post I wanted to inform you that now Microsoft has published a blog post that:
a) gives some more details on the root cause of the problem
b) outlines some possible workarounds and
c) most importantly : states a hotfix is in the pipeline which will be available in (late) Q2
You can find the full details here.
I ran into the same issue at one of my customers last week and have been working with Microsoft support to get this resolved. Below you can read some findings and experiences from the past days.
The workaround to Move wuauserv (Windows Update Agent) to its own SVCHost.exe instance did not prove to be very successful. Although we saw the scan job succeeding on a few clients at first, after a few additional scans the issue returned.
Next step was cleaning up WSUS. First we needed to verify what we could potentially clean up using the script provided by Microsoft:
To get things back on the rails in the end the only successful method was to run WSUS cleanup script to decline all superseded updates. Running the script with the –DeclineLastLevelOnly switch was not sufficient.
Important: Before running this cleanup script make sure to identify if any of the updates are still needed! It could be a superseding update has not yet been released due to your internal approval and/or release processes!
And while you are checking that also note that the script output may be misleading. Set the LastLevel column filter to False if you are actually looking for the Last Level Superseded Updates.
Running the script itself took around 15 minutes.
Note: if you are running multiple SUPS in your environment you should only run this on one SUP – the one with Windows Update set as synchronization source.
Hope it helps!
Earlier this week Microsoft has released the Outlook for iOS application. I have been using the application for the past few days and I personally find it a major improvement compared to the default mail application.
One thing I noticed straight away was that the badge counter indicating the number of unread emails did not display for the Outlook application. The counter did work fine for my old email app. As I am not using any other notifications (sound or display) for email I found this is a feature I quite heavily rely on when quickly checking for new mails. I needed to get this resolved.
First step I did for troubleshooting was to check the settings menu in the application to see if anything was hinting toward this option. There is a badge count setting, but other than switching between the Focused and All inboxes there are no other options to set.
When digging further into this I found that the key to solve this problem is in the notification settings for the application (in the general phone settings). Here I had to enable the Allow Notifications option first to reveal further options. The badge app icon is the one that I needed to enable.
The immediate result:
Simple fix for a simple issue. Why the Allow Notifications setting was disabled by default remains an unanswered question. A few of my friends installed the application as well and for them the badge count was enabled immediately.
I hope this may help you save some troubleshooting time in case you are also missing the badge count on your Outlook for iOS application.
Until next time!