Pinky: “Gee Brain, what are we gonna do tonight?” Brain: “The same thing we do every night, try to take over the world!”

Let’s cut to the chase – There isn’t an SCCM Dashboard out there which measures up against Callisto in looks, features and just downright usability.

I’ve been working with System Center Configuration Manager since, well, before it was called System Center Configuration Manager – SMS 2.0 and SMS 2003 it was back then. Since 1999/2000 – reporting in Configuration Manager has barely changed with perhaps the exception of the rather tedious text only reports finding themselves exported to SQL Server Reporting Services.

Refresh your world and try Callisto, the responsive SCCM dashboard product from Apajove which cuts through the quagmire of SQL and the horrid drill through behaviour of SSRS and brings your SCCM reporting experience to life. Grant access with varying levels of permissions to the dashboards to your users, management team and let them rejoice in how easy it is to browse key data about Configuration Manager patching, software deployment, Office and Windows 10 support status and so much more.

Go to https://getcallisto.io, like now, and get up and running with a fully functional trial in under 5 minutes, no purchase or card details required at sign up and best of all your full trial version reverts to a free community edition after the trial runs out. Win Win!

Callisto from Apajove, probably the best SCCM Dashboard in the world.

Windows 10 Versioning and Support Status at your fingertips.

Episode VI: Return of the Microsoft Display Dock

Remember this little dude? He’s back!

I went through the phase of owning a Microsoft/Lumia 950 phone, it wasn’t a bad phone at all but it was let down with application support.  It was supplied with a Microsoft Display Dock (HD-500), which you could hook up to the Lumia Phone, a Wireless Keyboard and Mouse and start using it as a mini Win10 desktop on a full screen monitor.  Cool tech!  Sadly, as Microsoft failed to make an impact in the phone market we all pretty much moved to Android or iOS – which consigned the phone and the dock to storage.

My desk setup nowadays is a Lenovo P50 laptop/workstation connected to a couple of 24″ QHD Dell monitors via a Dell Universal Display Dock, it works well.  I was rummaging around a box of cables the other day and came across this old Microsoft dock and thought – this still looks like a pretty cool piece of tech, I wonder if this thing still has any uses?  I gave it power, hooked it up to an HDMI monitor, grabbed a Dell Latitude 7280 with a USB-C connector and connected up the dock – lo and behold, it works!

All of the technical specs for the Microsoft Display Dock say it’s compatible only with certain Lumia devices, but it seems it’s quite happy to function as a dock/port-replicator for modern Windows 10 devices too.  Windows 10 detects the dock correctly and provides you with the same output to a second 1920×1080 monitor as you’d expect (extend/duplicate), along with 3 extra USB ports.

So don’t throw away your little old friend just yet, give him a try with your Windows 10 laptop – he might be your desktop friend once again.  If nothing else just throw it in your laptop bag – it’s still cool to use as an extremely portable dock.

 

 

 

#ExpertsLiveEU Apajove Session on #ConfigMgr Reporting

It’s been a while since I took time out to write something new on my blog, it’s been an exceptionally busy period working as Technical Director for Apajove, a UK based Microsoft System Center consultancy.  One of the amazing things we’ve been up to is the development of our on-premise web based responsive dashboard for your System Center data: Callisto.  Take a look at the video below and visit Callisto from Apajove to register and downoad a fully functional trial version.

Callisto has several overview dashboard pages, such as the Devices page which allows you to see at a glance the good and the bad, and pretty much everything is clickable to lead you into the data you’re interested in.  These highly visible main dashboard pages can be set to refresh and cycle automatically, allowing you to throw them up onto service desk wallboard screens.

A more recent addition to the Callisto pages is our Operating System Deployment dashboard that shows you how well your OS deployment is progressing.

Apajove are proud silver sponsors of Experts Live Europe 2018 in Prague and we’ll be taking a session on getting the most out of your System Center data via SQL and SSRS, leading up to how Callisto came about and what it can do to accelerate your consumption of the wealth of data buried away in your System Center databases.  We’d love to see you there, don’t be shy – say Hi!

Regards,

Andy

MDT Task Sequence for Building Remote Desktop Session Host with Desktop Experience

When using an MDT  Task Sequence to build/deploy a Server with the Desktop Experience component there are a few issues you may encounter.  Firstly, I would highly recommend you make use of the “Install Roles and Features” MDT step which uses the ZTIOSRole.wsf to install your selected Roles and Features and perform a reboot for each one if necessary.  It works well.  You can happily select all of the Roles and Features you need from the one step.  Secondly, be aware however that if choose to install the “Desktop” Experience Role (and possibly others) this requires some Component Based Servicing actions that trigger a hard reboot when the Task Sequence isn’t expecting one and your Task Sequence will fail.  You might not realise it has failed as the server will simply be sat at the CTRL+ALT+DEL screen.

I read a few blog posts, one of which in particular related to using DISM to manually install each role, with a reboot step between each and a set of commands for temporarily disabling the TrustedInstaller service.  I didn’t like the idea of that, and for me, it didn’t work anyway – when the service was re-enabled and the server was rebooted it simply triggered the hard reboot anyway.  You might get different mileage.

My solution was simply to ensure that there is a “Restart Computer” step immediately following the “Install Roles and Features” step that installs the “Desktop Experience” role – to restart back into the running OS with a 60 second countdown.  I actually had two “Install Roles and Features” steps, the first does .NET 3.5 and 4.5 and the second step has all of my RDS related Roles and Features selected (Ink, Media Foundation, Session Host, Licensing Diag tools, Desktop Experience). I think it is important that you have selected the “User Interfaces and Infrastructure” node too.

I found this fairly reliable in that when the Desktop Experience Role is installed along with other roles and the server is rebooted gracefully by the ZTIOSRole.wsf, the Task Sequence engine started back up again quick enough to trigger the next “Restart Computer” step and whilst the countdown was occuring the TrustedInstaller initiated the hard reboot within the first 30 seconds.  The Task Sequence continued without error.

After wasting many hours getting this all working using Server 2012, I wanted to capture this build using Capture media – however the PrepareOS step failed with an 80004005 error about unbcl.dll (c:\windows\system32\sysprep\panther\setuperr.log).  This doesn’t happen if you run SYSPREP manually or if you are using Server 2012 R2 – it looks like this is as a result of the Task Sequence running the SYSPREP utility under SYSTEM credentials (as it is a Capture Task Sequence basically.)  For the moment, I am having to resort to performing manual Prep of the Configuration Manager Client, SYSPREP manually and boot into WinPE from a USB/ISO and perform a manual capture using ImageX (well, GImageX actually.)

ConfigMgr 2012 R2 MultiCast issue smsts.log showing HRESULT=800705B4)

I have had the satisfaction of getting MultiCast working within a customer environment, which is rare among many customers that almost bring their networks to its knees by way of incorrect switch configuration.  Their network guy was a real credit and absolutely knew his subject – so I felt I had to demonstrate a similar level of ability with Configuration Manager when the problems encountered getting MultiCast working seemed to fall into my ball park.

The SCCM Distribution Point was enabled for MultiCast and the OS Image package was enabled for MultiCast distribution.  Firstly, I hit a seemingly common problem where the MultiCast session would fail to start, causing an error HRESULT=8004005 in the smsts.log.  The English text accompanying that error suggested that the MCSKey could not be properly obtained or was invalid from the MultiCast enabled DP.  So I followed these steps outlined in several other forums;

1. Un-checked Allow this package to transfered via multicast at package/image properties.
2. Cleared SerializedMCSKey and SignedSerializedMCSKey in registry (HKLM\Software\SMS\MCS).
3. Unchecked enable multicast at dp properties.
4. Checked enable multicast at dp properties.
5. Checked Allow this package to transfered via multicast at package/image properties.
6. Checked transfer this package only via multicast

I have no idea how, or why this works, I can only assume that the initial configuration of the MultiCast DP doesn’t work and that only when you clear out the Registry keys mentioned and follow the process above do things get set correctly.  Randomness.  After giving a few minutes between each step and a few minutes after to let things settle,  I started the testing process again.

I was now seeing a different error, HRESULT=800705b4 in the smsts.log accompanied by text stating that the hash value was incorrect. The hash value was of course incorrect but only because the file downloaded was empty, so I judged that this was not your typical remove/re-distribute package task.  The download of the .wim file never started so I figured it must be something file location / permissions related.

In many of my customer implementations, I consciously choose to enable the “Allow anonymous connections” setting on the Distribution Point – as this alleviates quite some load off IIS authentications and quietens down the mass of W3SVC logs an awful lot – but I had a little voice in the back of my mind asking me to consider if MultiCast might be impacted by this setting.  In all but the most security conscious environments I do not see enabling this option as a particularly big issue – given that the content on SCCM Distribution Points is generally open to any Domain Joined machine or Domain User that wants it.  Configuration Manager is usually always configured with one or more  “Network Access Account” to accommodate the download of files by systems during Windows PE phase of Operating System Deployment but I couldn’t be sure that MultiCast would play by the same rules and work anonymously, so to speak.

I disabled the option on the Distribution Point for “Allow anonymous connections” and started the deployments again and this time we saw the full glory of MultiCast among the 5 test systems being built.  The Performance Monitor on the Distribution Point clearly showed that when the client systems were all participating in the MultiCast session for the Operating System Image the Network data being transmitted only to a single MultiCast IP Address at a healthy rate.  The test systems had 1Gbps connections and all finished the “Apply Operating System Image” step in approximately 15 minutes.

I do like to see technology working!

Policy Evaluation Failed. Error Code 0x87d00267.

I have recently been engaged on a customer site who have been having all manner of random and frustrating problems with Operating System Deployments.  Sometimes the OS image would fail to download, sometimes the ConfigMgr Client would fail to download or install, sometimes any given application would fail to install.  Failure Status Messages include the below;

Install Software failed, hr=0x80070001. The operating system reported error 2147942401: Incorrect function.

 

Failed to configure OSD setup hook (0x80091007)
Configure hook failed with error code (80091007).
Failed to install setup hook (80091007). The operating system reported error 2148077575: The hash value is not correct.

 

Installation of image 1 in package P0100198 failed to complete.. 
he hash value is not correct. (Error: 80091007; Source: Windows). The operating system reported error 2148077575: The hash value is not correct.

 

They had been through all the usual Refresh DP/Validate/Remove/Re-add nonsense that sometimes fixes corrupt applications to no avail.  This all added up to something that is usually very unlikely to be the fault of Configuration Manager, the way it is configured or the applications within.  This had plagued them for weeks, months perhaps.

In the scenario where one or more of these errors were occuring when deploying physicsal clients from a physical distribution point, they found that something unusual was happening with their Riverbed setup – which was that whenever the task sequence rebooted and proceeded to try and install the next application, the HTTP session was somehow being interfered with by the Riverbed device – resulting in the client being unable to request policy after the reboot.  They took the Riverbed out of the equation and that resolved some physical > physical build issues.

Where we were experiencing one or more of the errors above in the VMware environment, it was discovered that most (if not all) of the VMware test client systems and VMware Distribution Point servers were configured with either the E1000 or E1000E ‘legacy’ Network Adapter.  Changing the client systems to use the E1000E didn’t help and we are not at a convenient point to include the VMXNET 3 adapters in the boot images (nor does the VMXNET 3 adapter support PXE Boot.)  It was therefore decided (by me, lol) to take a punt on re-configuring the Distribution Point Server to use the VMXNET 3 adapter.

Success!  VM DP to VM Client and VM DP to Physical Client deployments all taking place without any such random nonsense occuring.  A quick Google session revealed the use of the E1000/E adapters in VMware is generally bad Ju-Ju and so I implore you all to consider making sure that where possible you use the VMXNET3 adapter (Requires VMware tools installing) on your VM Distribution Points.

Task Sequence Install Applications 80074005, HTTP 401 Unauthorized

Always use the FQDN when specifying your Network Access (and possibly other) accounts within Configuration Manager, ie: “DOMAIN.COM\NetAccess”.  I found that this can resolve issues where you are building WORKGROUP or UNTRUSTED DOMAIN systems and they are failing to obtain content from the Distribution Point.  In short, it appears that IIS/Kerberos does not appreciate systems from other domains coming in and specifying the NETBIOS domain name as part of the Network Access Account, ie: “DOMAIN\NetAccess”.  This may be because systems in those domains have a different DNS suffix and/or are unable to resolve the NETBIOS domain name.

Failed to Sync Update. Error: The Microsoft Software License Terms have not been completely downloaded and cannot be accepted.

I was seeing the above error in the Configuration Manager 2012 SP1 wsyncmgr.log in a customer environment and I suspected this was as a result of SQL services being interrupted during the WSUS syncronisation process – which is never a good thing.  Despite trying to remove classifications and removing/reinstalling the SUP role the problem persisted.  When I loaded up the WSUS console and filtered for all updates I noticed that around 12 updates were showing that their content download (the EULA) had not been successfully downloaded.  I simply highlighted the affected updates, right clicked and chose to “Retry Download” and these changed to Pending Download and eventually all was OK.  A re-sync in Configuration Manager then resulted in a happy wsyncmgr.log and a successful sync event.

There is apparently a hotfix available for this issue which might be worth a try if you encounter this issue when proxy credentials are required;

http://support.microsoft.com/kb/2838998

Task Sequence step fails with ‘Incorrect Function’

This is just a quick post to help anyone out understanding what this error actually means.  In a task sequence, particularly an MDT integrated one, there will be tasks which use command line tools such as cscript.exe or xcopy.exe and when these fail to run you often get a traditional MSDOS based error code such as 1, 2, 3, 5 etc.  Error 1: Incorrect function, is usually when you have something that is running something like “cscript.exe myscript.vbs” but the script specified cannot be found to be ran.  Check your script location and paths.

.NET Framework failed to register Configuration Manager dll’s

I had a recent interesting experience where Configuration Manager 2012 SP1 setup completed successfully however there were problems lurking under the hood.  It was only until I proceeded to configure the environment and add additional roles that these came to light.  Several of the component installations failed, in particular those of the newer roles which require .NET 4.0 and their respective logs showed some very unusual errors I had never, ever, seen before.  The CloudMgr.log was absolutely full of instance creation errors.

At first I put this down to the Windows Server 2008 R2 virtual machine – it was based on an image and provided to me in a bit of a rush and with some history of a power failure/unexpected shutdowns – however a fresh DVD installation of the Operating System resulted in the same errors.  My attention then turned to the ISO media provided on the server that I extracted and performed the installation from – perhaps it was corrupt?  Not quite, but it was the cause of the problem.

The ISO file had been copied up to the server by somebody else over the network and for some reason the server took to marking the file in it’s properties with “This file came from another computer and might be blocked to help protect this computer” and gave me an unblock button.  I hadn’t noticed this and the result was that all of the subsequent extracted files were all marked the same.

The problem here is that the regasm.exe utility of .NET Framework 4.0, in it’s default configuration, will not permit the registration of dll’s that it perceives as coming from remote sources such as unc paths.

The answer here is not to proceed with the .config file editing solution offered by the only blog post I found regarding this error, it is simply to ensure that this attribute/property is not applied to any of the files from the Configuration Manager 2012 media before you start installation.  Attempting to patch the installation back together I am sure would be a futile and unsupportable task – there are simply too many possible errors introduced into the installation.  I even found that when you provision site roles on other site systems, the file attribute traveled with the dll’s copied to the remote site system and introduced role issues there.

It’s incredible, how something so random and inert could cause so many issues.