New update rollup for ConfigMgr Current Branch (1602)

Recently (May 27, 2016) for ConfigMgr Current Branch (1602) is released, also known as KB3155482. It fixes multiple issues on both ConfigMgr and Microsoft Intune. It cannot be downloaded, but will be available in the ConfigMgr console instead.

Here's a list of issues that are fixed:
-Remote Control (1x)
-Site Systems (1x)
-Microsoft Intune and mobile device management (5x)

As you can see it fixes mostly Intune (MDM) parts. When not using Intune, just wait for build 1606 coming soon.

This hotfix is available for installation in the Updates and Servicing node of the ConfigMgr console. If the service connection point is in offline mode, you have to re-import the update so that it is listed in the ConfigMgr console.

For more information on the update have a look here:
Microsoft Support

Hopefully the ConfigMgr certificate issue is solved now too!

Difference between Intune Standalone and ConfigMgr hybrid mode (part 4)

Recently I did some blogposts about the difference using Intune Standalone or ConfigMgr hybrid mode.
You can find them here: part 1 / part 2 / part 3

For ConfigMgr hybrid mode I mentioned the following:
As for ConfigMgr hybrid mode, this must be done in Configuration items and baselines, where not sure when they arrive. Monitoring - deployments is not the right place also, given a 'Unknown' status most of times. Did a lot of compliance checks and reboots on mobile devices, but nothing seems to happen..

Trick is, you need to do some additional configuration. When policies in Intune are working immediately, they are in ConfigMgr not.

When creating configuration items in ConfigMgr, "Remediate noncompliant settings" is turned on by default.

When creating and deploying configuration baselines, this is not the case. "Remediate noncompliant rules when supported" is not turned on by default. Trick is, you need to enable this for making them active.

In the baseline deployment properties "Remediate noncompliant rules when supported" must be selected. I did change the schedule for 7 days to 5 minutes too. After that configuration was starting on mobile devices right away.

Why this isn't configured by default is the question? Without this setting you can wait forever for policies to come through..

Difference between Intune Standalone and ConfigMgr hybrid mode (part 3)

In an earlier blogpost i wrote about pros and cons between Intune standalone and ConfigMgr hybrid mode, and the difference in speed between both solutions. This because Intune standalone (SAAS) is very fast (few seconds, sometimes few minutes) on enrollment of applications and/or policies. With ConfigMgr hybrid mode this is way slower, and can take up to multiple hours (or more) for making it happen. This time I want to share something on difference for Windows and Windows Phone devices.

With Windows 10, Microsoft is saying that there is One universal app platform, One security model, One management system, One deployment approach, and One familiar experience. Unfortunately that's not true when using a Windows 10 Mobile, managed by Intune standalone or ConfigMgr hybrid mode.

When deploying applications from one of both solutions, you will see that sometimes it's needed to choose Windows, the other time Windows Phone. Some apps are available for Windows, but not for Windows Phone (or the other way around). Very confusing if you ask me! So you must choose between a Windows app package or Windows Phone app package. That's hard to explain to customers..

When choosing a Windows app package (like I did), applications will not be offered on Windows 10 Mobile. In my perception this is not a Windows Phone anymore, with a different Windows Phone store. So yes, you must still use Windows Phone app package to make them available on Windows 10 Mobile. Very confusing if you ask me. Where does this fit in the One unified app store across devices, One great experience model? But wait there's more..

Within the post: Windows 10: A Store That’s Ready for Business, Microsoft is mentioning the following: 'with Windows 10 we will deliver one Windows Store for all Windows devices'. But therefore the new web-based Store portal must be used. So open Windows Store for Business and start adding apps to your inventory. When signing in with your Azure account (or add it next to your Live ID) a new tab in the default Store will be present.

After that a new tab is present in Windows Store, with the company name used, with apps added in Windows Store for Business. Because it can take up to 24 hours for the app to get present in the Private store, you must be patience on this :-)

More on that in a next blogpost. Thanks for reading.
Read more on part 1 and part 2

Difference between Intune Standalone and ConfigMgr hybrid mode (part 2)

In an earlier blogpost i wrote about pros and cons between Intune standalone and ConfigMgr hybrid mode. Is this post I will mention the difference in speed between both solutions. This because Intune standalone (SAAS) is very fast (few seconds, sometimes few minutes) on enrollment of applications and/or policies. With ConfigMgr hybrid mode this is way slower, and can take up to multiple hours (or more) for making it happen. This is very annoying indeed!
 
I'm using the SAAS solution myself; using it for demo purpose on my Windows 10 Mobile (Lumia 950). When doing enrollment on that and start a deploying applications and/or policies, they will be visible in a few seconds. Just have a look at some examples on that:
 

When deploying applications, or changing icons (or something like that), they are visible almost immediately.
 

When using Allow manual unenrollment (No), Intune cannot be removed from a Windows Phone or Windows 10 Mobile. Way better, because this isn't possible on iOS or Android devices, or special configuration is needed (iOS).
 

When using Allow application store for Windows 10 Mobile (No), the store isn't available anymore. Just an example how easy an application can be blocked, but again for Windows Phone only.
 

This for both the tile on start screen as for the start menu present on Windows Phones. They will be greyed out on start screen and start menu. Just want to see more off that.

When using Allow Camera (No), the following message is given, presenting a black screen when choosing OK. A message that the camera is blocked would be better I guess then presenting a black screen, but maybe it will be in future.

As for ConfigMgr hybrid mode, this must be done in Configuration items and baselines, where not sure when they arrive. Monitoring - deployments is not the right place also, given a 'Unknown' status most of times. Did a lot of compliance checks and reboots on mobile devices, but nothing seem to happen..

As mentioned in an earlier blogpost: Still I truly believe in ConfigMgr hybrid mode, having best of both worlds. But Microsoft still needs some development for a way better experience on that!

More on that in a next blogpost. Thanks for reading.
Read more on part 1 and part 3

Difference between Intune Standalone and ConfigMgr hybrid mode

When using Microsoft Intune, you can choose between Intune Standalone and ConfigMgr hybrid mode. Both have their own pros and cons. Microsoft is still recommending hybrid mode, because then you have best of both worlds. Point is, I'm not convinced anymore. Both ConfigMgr and Intune are great products, where Intune still need some development on new features. Customers are not always convinced about the solution, asking more enterprise features.
 

Having a look at my experience so far, I detect the following:
 
Intune standalone (pros):
-Easy to setup, Software As A Service (SAAS) solution;
-Can be managed everywhere with internet access;
-Very fast on enrollment of applications and/or policies (!);
-Can be used for both patch management & antivirus on endpoints with internet access;
-New features are released immediately.
Intune standalone (cons):
-With ConfigMgr in-place, two consoles for management;
-On some parts, less features then hybrid mode;
-You need to sign-in at every application change.
 
ConfigMgr hybrid mode (pros):
-Recommended configuration by Microsoft;
-Best of both worlds in a single management console;
-More features then Intune standalone;
-Deployment types and deployments are easier to handle.
ConfigMgr hybrid mode (cons):
-Less easy to setup; on-premises ConfigMgr infrastructure needed;
-Cannot be managed from everywhere, on-premises ConfigMgr console needed;
-Way slower on enrollment of applications and/or policies (!);
-Cannot be used for both patch management & antivirus on endpoints with internet access, because you need direct access or internet-based client management (IBCM) for that;
-New features will released slower in hybrid mode.

So yes, Microsoft is working on the feature part, and new features are available in ConfigMgr hybrid mode sooner. This because of the Service Connection point in ConfigMgr Current Branch.
But what's most annoying, You cannot have both patch management & antivirus on endpoints with internet access, because a ConfigMgr agent will be present on the device. Not an Intune agent, pointing to a SAAS solution. Therefore additional solutions like direct access or internet-based client management (IBCM) are needed.

And overall; when deploying applications and/or policies from Intune standalone, they are applied in few seconds. Within ConfigMgr hybrid mode it can take multiple hours (or more) when something happens. Still I truly believe in ConfigMgr hybrid mode, having best of both worlds. But Microsoft still needs some development for a way better experience on that! Hope they will soon :-)

More on that in a next blogpost. Thanks for reading.
Read more on part 2 and part 3

Using ConfigMgr 2012 R2 SP1 and Microsoft Intune in a Hybrid configuration

Within my daily job I'm doing Configuration Manager (ConfigMgr) and Endpoint Protection (SCEP) consultancy and training a lot. ConfigMgr is a great product for managing on-premises devices, like servers, desktops and notebooks. With Microsoft Intune, Mobile Device and Application Management on tablets and smartphones can be done. This is a standalone Software as a service (SAAS) solution which exists for multiple years now. When integrating both solutions, you have a Hybrid configuration in-place.

Benefit of using a Hybrid configuration is integration! You can manage both Windows, Mac and Mobile devices within a single management console. Just make sure to set the management authority (which can be set on Office 365, Intune or Configuration Manager) on the right one. When it's set on Configuration Manager no management has to be done in the SAAS console anymore. Just use collections, applications and policies which are in ConfigMgr by default, to manage mobile devices as well. On the different clients, a Intune Company Portal needs to be installed for management.

Last years Microsoft has done a good job to improve speed on client communication and policies. That way you can enroll a mobile device in a few minutes, publish policies and applications, and set an unenrollment (when needed) all within approx. 15/20 minutes. When forcing a Reset passcode (new passcode must be entered) or Remote lock (device is locked and passcode needs to be set again), it will be active in approx. 1/2 minutes. During unenrollment all configuration and apps are removed also. Reasons enough to stay enrolled.

With Windows 10 Mobile coming, the richest set on policies can be configured. When creating policies (configuration items), you will see the difference on Android, iOS and Windows (Phone) platforms. Hope that will be better and easier in the future. It's possible also to deploy applications (from the different app stores) and weblinks to mobile devices. You can choose to open them in a web browser or install them. During installation a shortcut is created in Apps, so no need to open the Intune Company Portal again.

Hope to have some real experience on Windows 10 (Mobile) soon. It looks like the choice is really easy now! Just use Windows 10, Azure Active Directory (AAD), Enterprise Mobility Suite (EMS/Intune) and ConfigMgr from now on. That way Microsoft can convince you on the new generation available, which is Mobile first, Cloud first. Windows as a service, ConfigMgr as a service (2016) and Software as a service! I'm very excited about this, hope you are too?!

The following can be found on the "In the cloud" blog:
While there have been many improvements to the MDM capabilities, not every management capability exists – yet. To solve for this, we have effectively built a “bridge” between the ConfigMgr agent and the MDM agent which enables the agents to co-exist and expose all the existing manageability that you know today – as well as the new functionality that is being exposed via MDM to be manageable from the ConfigMgr console. No one else (traditional PC management or EMM vendor) has done any work like this. This is another HUGE reason that ConfigMgr + EMS is your best solution for deploying and managing Windows 10.

Just great if you ask me :-)

How to reset your MDM authority in Microsoft Intune

When starting with Microsoft Intune, you must setup a MDM (Mobile Device Management) authority to continue. This MDM authority can be set on Microsoft Intune (using the SAAS solution), ConfigMgr (using the hybrid solution) or Office 365 (included with Office 365 commercial subscriptions). During a hybrid installation (which is ConfigMgr connected with Intune) the MDM authority was already set to Office 365. That way it isn't possible to connect it with ConfigMgr.

Unfortunately the only way to reset your MDM authority is to call Microsoft Intune support and wait 5 business days at maximum to get the job done. After that it can be configured for Intune or ConfigMgr again. Hope that Microsoft can simplify the process in the future, so that people can do it themselves. Very annoying to wait several days, when you know the action can be done within a few minutes.. 

When the reset has taken place (there may be no devices enrolled within Microsoft Intune), you can set the MDM authority again. Just make sure to choose the right one this time :-)

Note: Microsoft mentions that the reset is done in US only, so no luck for EMEA people who want to have a quick result.

Update: In the end it took almost 6 (!) days to reset the MDM authority. My project is delayed 2 months because of this.

Contact details:
Microsoft Intune support
Contact Assisted Phone Support for Microsoft Intune

Most wanted features in ConfigMgr requested by customers

In my daily work I'm doing ConfigMgr implementations a lot. Multiple features missing in ConfigMgr 2007 were implemented in the 2012 release, which is still an awesome product (if you ask me)! Let's have a look at the most wanted features requested by customers. Don't know for sure what the 'vnext' release will bring, but still want to mention them. When having more, just leave a comment.

1) Hash value error during deployment: When updating a single package during deployment, which is part of a OSD task sequence, it fails because of hash value. When having a large enterprise company, it's hard to explain this! Maybe OSD and packaging are different teams then. Or people are working 24 hours around the globe in a single ConfigMgr Site. Just offer both old and new hash for a few hours and don't let the task sequence fail because of this! A colleague mentions: When this is the case, ConfigMgr isn't an enterprise product, and I think he is right on this point. (Must check it again)
2) Continue task sequence after error: It's crazy that when a task sequence fails (which happens a lot during testing), you cannot restart the task sequence from the point it fails. One mistake and you can start all over again, or you must enable "continue on error" on every step or group. Why not ask a question if you want to continue OSD after all? Makes life a lot easier during imaging.
3) User Environment Management (UEM): When customers want UEM functionality, they must use Group Policy, Preferences, MS UE-V, RES Workspace Manager, Imideo Flex Profiles or AppSense. Why not building more of Group Policy and Profile management in ConfigMgr, so you have best of both worlds? Hope that this part is available in the 'vnext' release, because Windows 10 may be controlled with ConfigMgr completely! Source: Windows 10 enterprise management with System Center Configuration Manager and Intune
4) Application control after deployment: When customers using ZENworks Configuration Manager (ZCM), it's hard to sell the ConfigMgr product. This is not because of imaging, which is a very strong selling feature! It's because of UEM and application control, which is part of ZCM by default. No way you can deploy shortcuts and decide on which time an application becomes available and on which time it's removed. This feature is requested in education a lot, where exams must be available on specific times only. Hope this will be way better in the 'vnext' release, not only on Windows 10, but on applications also.
5) Show collection membership for systems: One of great features of Powershell Right Click Tools, which let you you see in which collections a system or user resides. Should be default functionality in ConfigMgr if you ask me. Why not adding more management tools by default on systems and collections?
6) Black screen when using remote control: Hide the screen from the end user, when typing in sensitive information. Can be a valuable feature, because other remote tools offers this functionality also. Instead of a black screen, a message like "work in progress, please wait" is a nice-to-have also.
7) Change Distribution point (DP) when not available: When you have multiple DP's in the same IP-range, and content is available on one DP only, ConfigMgr is waiting for content and fails afterwards. Content is randomly selected on DP's, so you don't know at forehand which DP is selected per package. When adding content during deployment on the other DP, it will still continue (lucky enough). Better would be, when ConfigMgr doesn't see the needed content on a DP, it will use another one automatically.

Update 15-4-2015:
8) Enforce installation or upgrade during logon/logoff: Software installation can take place when a user is logged on or logged off, but sometimes you want to update a critical component. Best thing to do is to enforce this during logon or logoff, like Group Policy, without the possibility to use the component on the system. This isn't possible at the moment, so companies which are in 24/7 business, have a challenge that way.

Hope that some of features mentioned here are build-in a next release, or added at a later time. Time will tell ;)

Network selection during Windows 8.x deployment in MDT and ConfigMgr

When deploying Windows 8.x with MDT or ConfigMgr, deployment may stop at the network selection screen. When press Connect in the selection screen, deployment will continue. Within this blogpost I show you how to skip network selection.

 
Within MDT:
The CustomSettings.ini (which can be found on Properties, Rules on the Deployment Share) needs to be changed as follows:
 
<OOBE>
   <HideEULAPage>true</HideEULAPage>
   <NetworkLocation>Work</NetworkLocation>
   <ProtectYourPC>1</ProtectYourPC>
   <HideLocalAccountScreen>true</HideLocalAccountScreen> 
 <HideOnlineAccountScreens>true</HideOnlineAccountScreens> 
 <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
</OOBE>
 
Within ConfigMgr:
The unattend file (additional file which can be used in the Apply Operating System step) needs to be changed as follows:
 
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">    <settings pass="oobeSystem">
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <OOBE>
                <HideEULAPage>true</HideEULAPage>
                <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
                <NetworkLocation>Work</NetworkLocation>
                <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
                <HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
                <HideLocalAccountScreen>true</HideLocalAccountScreen>
            </OOBE>
            <RegisteredOwner>Microsoft</RegisteredOwner>
        </component>
    </settings>
    <cpi:offlineImage cpi:source="" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

For x86 systems, change "amd64" in "x86" to get the job done.
 
Source locations:
Windows 8.1 deployment in MDT 2013
Windows 8.1 prompting for network (some lines missing)
When using the script from TechNet, the red lines are missing. Therefore an error message is displayed during mini-setup (about /unattend) and deployment stops on that point. Now way you can pass a deployment error during mini-setup, so just use the unattend file mentioned here. Hope it helps!

New ConfigMgr Hotfix speeds up retire or wipe to seconds

Last month a new ConfigMgr hotfix became available, specific for Mobile Device Management devices in Microsoft Intune. This hotfix greatly reduces the time that's required to execute a successful retire or wipe of an MDM device by using a notification to "push" these tasks. Without this hotfix, retire and wipe operations could require 24 hours to run successfully, because they relied on a "pull" mechanism of this frequency. This happens with me on installations also, where retirement could require 24 hours of even more!
 
After you apply this hotfix, retire and wipe operations are pushed to the following MDM device types: iOS, Android, Windows 8.1
These operations now run on the device in a matter of seconds, assuming the device is reachable by Microsoft Intune. The device must have an active data connection for Intune to communicate with it. Just great that this ConfigMgr Hotfix speeds up retire and wipe operations to seconds!
 
Note: If a device is not reachable by Intune when a retire or wipe operation is requested, the operation will run the next time that the device comes online and connects with the Intune service. This could require up to 24 hours.

To apply this hotfix, you must have Cumulative Update 3 for ConfigMgr 2012 R2 installed.

Download hotfix: Microsoft Support

ConfigMgr Offline Servicing on Volume License media

When using Offline Servicing in ConfigMgr to integrate software updates, it's easy to inject around hunderd updates in a Windows 7 SP1 image (for example). This week I started to inject around 100 updates in a Windows Server 2008 R2 SP1 image. This is however a Volume License media with 8 catalog files available. When selecting from a task sequence you have the following choices: 

 
Trick is however that when using Offline Servicing for this image, it will start the DISM process 8 times also! No way you can choose to inject them on 1 catalog file only. In my case this results in 8 times injecting 110 updates, which will takes lots of time. I rest my case on this one and install updates during Build and Capture, and not using Offline Servicing which I prefer. Too bad there's no option too choose the right Windows edition here, or didn't I find it yet? 

When the DISM process is started already, you can choose to run Configuration Manager Service Manager (ConfigMgr console > Monitoring > Component Status > Start) to stop the responding proces, because of too much time. Hope it helps!

Event 10102, Health Service Modules, PerfDataSource warnings

On a ConfigMgr server at customer location I did see a lot of Event 10102, Health Service Modules, PerfDataSource warnings. Every 75 minutes, there were a lot of warnings detected, and customer want me to resolve this. Let's have a look.

A warning was looking like this:
In PerfDataSource, could not resolve counter SMS Inbox, File Current Count, swmproc.box>usage. Module will not be unloaded.
One or more workflows were affected by this. 
Workflow name: Microsoft.SystemCenter2012.ConfigurationManager.Perf_Threshold_Site_server_SWM_inbox_backlog_monitor
Instance name: ConfigMgr Primary Site Server - <removed>
Instance ID: {ECB782E3-F42F-23D2-C609-65CC8B78BA48}
Management group: <removed>

Because this message was coming from Operations Manager, and the OpsMgr Action account was configured on local system, I thought it would be a good idea to have a look at local administrator permissions. Long story short, I added both ConfigMgr SYSTEM account and SQL service account to the ConfigMgr server local administrator permissions, and after reboot no warnings were there anymore. In the end it was a security issue after all. Hope it helps!

The future of ConfigMgr is uncertain for sure!

You all heard the news, Wally Mead, the foremost authority on System Center Configuration Manager (SMS/SCCM/ConfigMgr) and a leading figure within the community, will leave after spending over 22 years with Microsoft. Because of that it's almost like ConfigMgr died too! This emphasizes how Microsoft is changing. ConfigMgr is strictly an on-premises technology and Microsoft is moving us all to the Cloud.
 

 

So after killing Microsoft Management Summit (MMS), this seems to be the next step for Microsoft. Let's have a look at the changes coming. It all has to do with Mobile First/Cloud First vision.
 
Starting this year we are merging MMS with TechEd
Over the past 11 years, the Microsoft Management Summit (MMS) has grown from a small user group event focused on systems management and managing PCs, to a large and passionate gathering of the world’s best and brightest IT Pros. Now it’s time to look ahead to the next step for our industry and this community. Starting this year we are merging MMS with TechEd.. (and so it will be)
 
After merging MMS with TechEd rumours say 2014 could be the last year Microsoft holds a TechEd event.
 
No MS TechEd next year anymore?
If the rumors are right, this year's TechEd may be the last. The content at TechEd North America this year also is expected to include some management-specifc tracks, as the Microsoft Management Summit (MMS) is now being folded into this show. (If MMS content is available on TechEd Europe too is not sure)
 

During the TechEd 2014 Keynote Sneak Peek the message was clear for all IT Pros: Go Cloud or go home.
 
TechEd 2014 Keynote Sneak Peek
Intune is ConfigMgr delivered from the cloud. Last Fall we created a strong connection between both of them for use in a hybrid cloud model. Today there are more than 10k customers using Intune to manage their PCs and devices. The choice is yours: Do you want to manage on-prem or from the cloud -- we give you the option to do either. (For how long it takes)
 
Given the fact that the ConfigMgr team is same as the Intune team (and most resources are on Intune, because Microsoft still has a lot of catching up to do, and ConfigMgr is in a finished, almost perfect state), there will be less development on ConfigMgr for the next years. You can see this in the Windows Intune Roadmap also. Focus is on Windows Intune as a cloud solution, not providing functionality which need ConfigMgr integration anymore. (Richer cloud-only MDM capabilities, Full MDM parity in Windows Intune standalone)
 
And also: With the added development focus (at the expense of ConfigMgr), it won't be long before Windows Intune is an exact match, further blurring the lines of how endpoints are managed. If Microsoft can show that managing on-premise endpoints from the Cloud is viable, ConfigMgr could be history.
 

And now, Wally Mead, the Face of ConfigMgr, Leaves Microsoft after 22 Years. Thanks Wally for being a great inspiration for me, and good luck with your new job as Principal Program Manager at Cireson!
 
Microsoft's Wally Mead Joins Cireson as Principal Program Manager
Wally Mead, pioneer of Configuration Manager, joins Cireson and strengthens the growing System Center focused organization.

Wally Mead, the Face of ConfigMgr, Leaves Microsoft after 22 Years
During one conversation with Wally, he indicated that when Microsoft decided to push ConfigMgr completely into the Cloud, it would be time for him to retire. I won't state that Wally leaving Microsoft indicates anything more than a simple professional change, but it is interesting timing since we're anticipating roadmap announcements at TechEd 2014 in a couple weeks.
 
Rod Trent (CEO & Founder at myITforum.com, Inc.) reacted on the topic with: I think it's safe to put it this way: MMS is dead. Microsoft is moving us all to the Cloud. And, Wally Mead has left Microsoft.
 
So.. The future of ConfigMgr is uncertain. Let's move to the cloud now, that's the message! Lucky me I will do a lot on Intune next months..

WSUS Post Deployment Configuration Fails on Windows Server 2012

Last week I had an issue on my ConfigMgr server with local WSUS installation. The WSUS (Windows Update) service couldn't be started and Server Manager (in Windows Server 2012) RTM gives an error message also: The WSUS content directory is not accessible. In this case no (new) update management is possible anymore.


Sample from Event Viewer

Lucky me I found the issue reading the following posts:

WSUS Post Deployment Configuration Fails on Windows Server 2012
http://blogs.technet.com/b/reshard_sharps_blog/archive/2013/08/18/wsus-post-deployment-configuration-fails.aspx
It mentions: When using SQL for your database instance you must specify the name of your SQL server. One would assume if the database is local the wizard would find the instance without specifying the SQL server name. If you select Check Connection without specifying a server name it will return Successfully Connected to server. Despite this misleading result, it was not successful. The server name value it expects when running the Post Deployment step will be empty and will cause Post Deployment to fail.

WSUS install on Server 2012 Fails
http://social.technet.microsoft.com/Forums/windowsserver/en-US/91e45363-bbf7-414a-8932-779b1c170c3e/wsus-install-on-server-2012-fails?forum=winserverwsus
It mentions: I solved this issue by opening IIS Manager and deleting the old WSUS web site, then running the Complete WSUS Installation again.

What you have to do is uninstall WSUS, remove the IIS website manually, keep the WSUS database (it won't be removed after all) and reboot the server. After reboot install WSUS again, choose to check connection with the SQL server filled in, and start Post Deployment. This time it will work fine again!

How to manage Obsolete clients in ConfigMgr

When deploying devices multiple times a day, for example when testing a new Task Sequence, ConfigMgr clients will become obsolete. This because everytime a device gets a new image, the ConfigMgr client will be installed again with a new GUID. The older object will be marked as obsolete, and a new object becomes available. Because of this obsolete object, OS deployment and Software distribution doesn't work anymore. This can be managed as follows.

First configure a Maintenance task for deleting them automatically. Go to Site Management > Site Settings > Site Maintenance > Tasks for enabling and configuring "Delete Obsolete Client Discovery Data". This way daily management of obsolete clients is not needed anymore. Mostly the following configuration I choose at customers:

This because this task is disabled by default, and deletes only data older the 7 (seven) days. Because I want a daily refresh in colllections, I choose to set it to 1 (one) day. This is the only thing in ConfigMgr for automatically deleting obsolete clients. But what to do when there will be multiple deployments on the same day, with the same device? Then manually delete the obsolete client is needed. For doing that, the following must be done:

Go to the All Systems collections and choose "Update collection membership". Also do a refresh afterwards. Then multiple objects can be available for the same device. Delete the Obsolete one will also then delete this object from other collections. That's pity! So remember to which collection(s) this device belongs! There is also another way for recognizing multiple objects.

Go to the collection where your device is placed for OSD (for example). Now rightclick on this collection and choose properties > Membership Rules. Click the blue computer icon for adding new devices:

Choose System Resource (Resource class) & Name (Attribute name). Fill in the device name searching for (Value):

Don't use Collection Limiting for searching devices, otherwise you have less change to find them:

When having obsolete client data, multiple devices will be seen. Choose "Select All" for adding them to the collection:

After that new devices are added, and obsolete items can be deleted:

When devices are in the right collections again, advertisements will be functional again. These are all workarounds for managing obsolete clients in ConfigMgr. When there are more possibilities for managing them , I like to hear them. Managing obsolete clients stays a challenge this way!?

Update: You can also use a query on the client name to manage collection membership instead of direct allocations. That way the new clients appear in the same collections as obsolete ones automatically. (thanks to arricc)

Advanced Driver Management in ConfigMgr 2007

With ConfigMgr advanced driver management is possible for all kind of devices. Best practice for this is creating driver packages for all different devices, and put them in the Task Sequence used for deployment. With WMI queries you can decide then which driver package will be used on different types of devices.

For more information about that see my other blog: Driver management in ConfigMgr 2007 http://henkhoogendoorn.blogspot.com/2010/10/driver-management-in-configmgr-2007.html

Now drivers are seperated in different driver packages, but what to do with the Drivers folder where all single drivers are placed? For all drivers imported there can be folders created, for dividing different drivers and hardware. Also specific Categories can be created for recognizing drivers and hardware by model. Do the following for that:

As you can see I've imported HP8000 drivers, which has been assigned to a new category. Press Next for importing this drivers in the ConfigMgr database.

All drivers are successfully imported in the ConfigMgr database. Now do it again for a new type device or model.

Now I've imported HP8100 drivers, which has also been assigned to a new category. Press Next again for importing this drivers in the ConfigMgr database.

This time (all) drivers will fail to import in the ConfigMgr database. Why is that? This because drivers can be already existing in the database. Default in ConfigMgr 2007 there can be only 1 instance per driver in the database!

But.. There is a hotfix available for solving that! (kb2213600)
http://support.microsoft.com/kb/2213600

With this hotfix drivers can be multiple times imported in different folders. So I install this hotfix in my environment, and do the same thing as before.

This time all drivers are indeed successfully imported in the ConfigMgr database. Let's have a moment now to look in the ConfigMgr console.

In the ConfigMgr console drivers are seperated now by device and hardware model. This way everyone can see to which device the drivers belongs!

When creating driver packages now, it's easy to see that the structure for driver management is the same in both Drivers and Driver packages. This way advanced driver management is created in the ConfigMgr console!

Once last thing: when deleting older drivers in the ConfigMgr console, this drivers will also be deleted from older folders from different models. To prevent this create an OLD folder, and move the old driver folders (model) beneath the OLD folder.

Also a collegue of mine (Stephan Wibier) has found that when a txt file exist in the driver source folder, this will not happen. Drivers that are the same for different models will then not deleted. This text file must exist in all folders and sub-folders then, for all drivers that are imported. This txt file has named in this example HP8000.txt for the HP8000 driver folders, and HP8100.txt for the HP8100 driver folders.

Hope you learned a lot this way about advanced driver management in ConfigMgr 2007!

Follow us on Twitter:
Henk Hoogendoorn (PQR) @henkhoogendoorn
Stephan Wibier (PQR) @stephanwibier

How to uninstall applications with ConfigMgr

With ConfigMgr 2007 it is possible to publish MSI applications. But what to do when there is an update for a specific application? In this blog I will explain what to do for removing the existing application on devices, and publish a new version of it. Then ConfigMgr is not only the recommend solution for updating App-V packages, but also for MSI applications!

First create a MSI-based application and program in ConfigMgr. Important detail is then to fill in the Windows Installer information! With this information it is possible for ConfigMgr to uninstall applications from devices. For doing this go to the "Windows Installer" tab in the program, choose Import, and browse to the MSI file of the application. Then the "Windows Installer product code" will be automatically filled in.

Do this for all MSI-based applications! With applications that are only available as EXE file, use a "EXE to MSI file" solution for creating MSI files of all applications that will be installed (and/or updated) with ConfigMgr.

Now what to do for updating the application? Best practice is to uninstall it first (or a in-place upgrade must be possible)! Create a new program (in the application itself) for that. In the program the following information must be placed:

In this case the following Command line is used: msiexec.exe /x {FC7BACF0-1FFA-4605-B3B4-A66AB382752D} /qn (example)
No need for fill in Windows Installer information in this program. Choose "Whether or not a user is logged on" on the Environment tab.

Advertise this new program to the collection where specific clients are been, and wait till the program will be uninstalled. When it is removed a new update for this application can be installed. In the Event Viewer this information can also been found.

When a update from a specific application must be done, with uninstalling the older version, the following can be done:

Create a new Software package, and choose on the Advanced tab for "Run another program first". Select the remove/uninstall program for the old application, and update the MSI application. That's all you have to do for uninstalling or updating applications!