SSO with OpenDNS using ADFS

1.  Log into your OpenDNS account.  From the Umbrella control panel, click Configuration.
   
   
   
2.  A panel will open on the left.  Expand System Settings, select Login Security and then click SAML from the Security Type options on the right.
3.  Choose Other and select Next
4.  Download the XML Metadata to configure your ADFS servers.  At the time of this document, the XML files were available using this link. 
5. Switch over to your ADFS server and configure the relying party trust.
1.  On your primary ADFS server, open the ADFS console and expand ADFS FS > Trust Relationships.  Right click on Relying Party Trusts and choose Add Relying Party Trust.  This will open the Add Relying Party Trust Wizard.  Click the Start button.
   
2.  On the Select Data Source screen, choose Import Data about the relying party from a file.   Browse to the XML file that you downloaded from OpenDNS and click Next.
   
   
   
3.  Provide a Display Name and add any notes you may wish to save.  These do not matter to the configuration and are for your use only.  Click Next.
   
4. The default choice of I do not want to configure multi-factor authentication settings for this relying party trust at this time should be selected.  Click Next.
   
   
   
5. Choose the default of Permit all users to access this relying party and click next.
   
   
   
6. You will now be given an option to review the settings for the new RP.  You can review them if you’d like, but most of these settings were automatically created for you when you imported the XML.  Click Next.
   
7. Once the RP is created, right click on it and choose Edit Claim Rules.  You can also use the dialog box to open this automatically if it pops up for you after the save is complete.
   
8.  Create two Issuance Transform Rules.  The custom rule language is provided for each of the require rules.
   
   RULE: AD to SAML
   c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"), query = ";mail;{0}", param = c.Value);
   
   
   
   RULE:  Email to Name ID
   c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");
   
9. Switch back to the OpenDNS page and click next to continue the configuration.
   
6. Download the metadata from your ADFS server and upload it to OpenDNS using the browse dialog.  You can retrieve your XML configuration using the following URL
   
   https://myadfsserver.fqdn/FederationMetadata/2007-06/FederationMetadata.xml
   
7.  After uploading the data to OpenDNS, you will be moved to the Validation step.  Enter your email address and test the validation.  If it is successful, continue through the wizard and save your changes.  Once saved, you should have SSO configured.

Detection Method: Language Pack

This simple powershell script will help you discover if a language pack is available.  It works great an an SCCM detection method if you are deploying language packs as using the Application Model.

If ((get-wmiObject -class Win32_OperatingSystem).MUILanguages -contains "zh-CN") { write-host $true }

Just substitute zh-CN with the language code of your choice.  View the larger list here.

Microsoft Rights Protected Folder Explorer Setup Wizard ended prematurely

Microsoft's Rights Protected Folder Explorer is a utility that Microsoft released to allow you to use Rights Management on any file type.  It works very similar to a zip/unzip application by allowing you to create an RPF file and sticking unencrypted files into it.  It will encrypt/decrypt using Microsoft's RMS policies that are defined in your environment.

This application is going away.  If you're looking for a this ability, you should be aware that support for the software will end on 8/27/2015.  Microsoft has replaced the application with a much better product called the Microsoft Rights Management Sharing Application.  This app will let you protect anything with RMS works a lot better than Rights Protected Folder Explorer.

Unfortunately, I need to make RPFE available.  To deploy it, I chose App-V 5.

During the sequencing, I stumbled upon a weird error.  With some trial an error, I was able to decode the log file and figure out what the problem was.

The error was:

Microsoft Rights Protected Folder Explroer Setup Wizard ended Prematurely
Microsoft Rights Protected Folder Explorer Setup Wizard ended prematurely because of an error.  Your system has not been modified.  To install this program at a later time, run Setup Wizard again.  Click the finish button to exit the Setup Wizard.

This error occurs right after you agree to the EULA, and is about as worthless of an error as you can get.

Knowing a bit about how Microsoft Installs software, I went looking for an MSI install log.  I managed to find one in %appdata%\temp\1 called Setup_rpfe00001.log.  

Bonus Tip:  When looking for a reason  your installation failed, always search MSI logs for the string "value 3".  

Searching for "value 3" brought me to the following section in the msi log.

MSI (c) (00:54) [10:30:59:510]: Attempting to enable all disabled privileges before calling Install on Server

MSI (c) (00:54) [10:30:59:510]: Connected to service for CA interface.

Action ended 10:30:59: RetrieveMuOptInStatus. Return value 3.

DEBUG: Error 2896:  Executing action RetrieveMuOptInStatus failed.

The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: RetrieveMuOptInStatus, ,

Action ended 10:30:59: WelcomeDlg. Return value 3.

MSI (c) (00:08) [10:30:59:666]: Doing action: FatalError

I chose to focus on RetrieveMuOptInStatus portion of the error as it looked rather unique.  Unfortunately, I couldn't find anything on it.  It's clearly some sort of optin dialog, and I took a stab and guessed that MU was Microsoft Updates.

Now, if you're looking to put this into App-V, things should be clicking.  One of the biggest rules is to make sure that Windows Update is disabled while you're sequencing because you don't want any service interaction to get recorded into your package.

To make this work in App-V 5, I just enabled the service, installed the application, and then disabled it again.  I then went through the registry and cleaned out anyt references to the Windows Update service (there were only a couple and it should be easy to find).

To summarize the problem, the installer is trying to talk to Windows Update to see if you want to use Microsoft Update.  It can't talk to Windows Update so it aborts.  The fix is to enable Windows Update while the application is installing.  You can turn it off as soon as you're done, but it has to be on during the initial portion of the install.

Visual C++ Runtime Information

Visual C++ Runtime Versions

This information was collected while adding Visual C++ runtimes to SCCM to deploy as applications.  Hopefully this will help you speed up you deployments.

MSI Product Codes and Versions

Version	Arch	Product ID	Version
2005	x86	{A49F249F-0C91-497F-86DF-B2585E8E76B7}
2005SP1	x86	{7299052B-02A4-4627-81F2-1818DA5D550D}	8.0.56336
2005SP1MFC	x86	{710f4c1c-cc18-4c49-8cbf-51240c89a1a2}	8.0.61001
2005	x64	{6E8E85E8-CE4B-4FF5-91F7-04999C9FAE6A}	8.0.50727.42
2005Sp1	x64	{071C9B48-7C32-4621-A0AC-3F809523288F}	8.0.56336
2005SP1MFC	x64	{ad8a2fa1-06e7-4b0d-927d-6e54b3d31028}	8.0.61000
2008	x86	{FF66E9F6-83E7-3A3E-AF14-8DE9A809A6A4}	9.0.21022
2008SP1	x86	{9A25302D-30C0-39D9-BD6F-21E6EC160475}	9.0.30729.17
2008SP1ATL	x86	{1F1C2DFC-2D24-3E06-BCB8-725134ADF989}	9.0.30729.4148
2008SP1MFC	x86	{9BE518E6-ECC6-35A9-88E4-87755C07200F}	9.0.30729.6161
2008	x64	{350AA351-21FA-3270-8B7A-835434E766AD}	9.0.21022
2008SP1	x64	{8220EEFE-38CD-377E-8595-13398D740ACE}	9.0.30729.17
2008SP1ATL	x64	{4B6C7001-C7D6-3710-913E-5BC23FCE91E6}	9.0.30729.4148
2008SP1MFC	x64	{5FCE6D76-F5DC-37AB-B2B8-22AB8CEDB1D4}	9.0.30729.6161
2012	x86	{33d1fd90-4274-48a1-9bc1-97e33d9c2d6f}	11.0.61030
2012	x64	{CF2BEA3C-26EA-32F8-AA9B-331F7E34BA97}	11.0.61030
2013	x86	{ce085a78-074e-4823-8dc1-8a721b94b76d}	12.0.21005
2013	x64	{7f51bdb9-ee21-49ee-94d6-90afc321780e}	12.0.21005

Install/Uninstall Switches

2005
Install	"vcredist_x64.EXE" /q:a /c:"VCREDI~1.EXE /q:a /c:""msiexec /i vcredist.msi /qn"""
Uninstall
2008
Install	"vcredist_2008_x64.exe" /q
Uninstall	"vcredist_2008_x64.exe" /qu
2010
Install	"vcredist_2010_x64.exe" /q /norestart
Uninstall	"vcredist_2010_x64.exe" /q norestart /uninstall
2012
Install	"vcredist_x64.exe" /install /quiet /norestart
Uninstall	"vcredist_x64.exe" /uninstall /quiet /norestart
2013
Install	"vcredist_x64.exe" /install /quiet /norestart
Uninstall	"vcredist_x64.exe" /uninstall /quiet /norestart

SCCM 2012 R2: Package fails to distribute, but all logs and graphs say that it distributed sucessfully

Problem:

While distributing content to a Distribution Point, Configuration Manager may report that the package has been distributed successfully.  However, any dependencies on this package fail as if the package does not exist.

Information:

I opened a case on this issue with Microsoft.  After a few days of troubleshooting, we determined that this is a known issue with SCCM 2012 R2.

It is really easy to determine if you are impacted by this bug.  After deploying a package, and getting a successful distribution (green pie chart, logs file indicate success, etc), open the monitoring context and select the package you just distributed.

Examine the package size.  If you are impacted by this bug, the package size will show as 0.00MB.  While it's possible that a package is this small, most packages are not.

In my case, the package I was trying to transfer was made up of about 1GB of drivers.  SCCM thought the package was empty and distributed an empty package to all my Distribution Points.  Since the empty package transferred successfully, there were no errors in the status messages.

Resolution:

From the software library context, find the package.  Right click on the package and choose Update Distribution Point.

It can take some time before the console reports any change.  You can monitor this process using the Distmgr.log file.  You will see entries indicating that distmgr is taking a snapshot for the content, and eventually you should see an entry that says "Successfully created/updated the package ".  Once you see this line, refresh your console and you should now see the proper size and it should start sending do your DPs (assuming there are free threads for this to happen).

As you can see in the image above, as soon as the Update Content was initiated, the size was corrected and my compliance went from 100% to 0.0%, which is good!  This means SCCM is actually transferring the bits of the driver package instead of an empty folder!

OSD: Task sequence fails with "CCMCORE.DLL is missing" error message

Problem:

When installing an operating system using SCCM OSD 2012 R2, the task sequence process the step 'Setup Windows and ConfigMgr'.  During the last portion of the step, an error message occurs:

The program can't start becuase ccmcore.dll is missing from your computer.  Try reinstalling the program to fix this problem.

Clearing the error message results in the machine displaying a login prompt.  At this stage, restarting the machine causes the OSD build process to continue.

Work Around:

During the task sequence, the variable OSDPreserveDriveLetter is set.  This is used to force the operating system to install to C: instead of D:

Disabling this action allows the installation to continue successfully, but the operating system is installed to D:.

Solution:

I was able to resolve this by running my build and capture sequence again to create a new baseline image for my task sequence.

Note from Microsoft:  The support engineer suggested to put the OSDPreserveDriveLetter variable (set as false) into the build and capture sequence, just before it captures the WIM.  While I don't think this had anything to do with the solution, you may want to try it.  All documentation that I found on this variable indicated that it was valid only during deployment, not during capture.

KB2887822 Fails to install (or my headache when upgrading AppController 2012 SP1 to R2)

In order to upgrade AppController 2012 Sp1 to R2, you must first apply Rollup 2 or higher.  However, trying to update to this version might cause you a point of frustration if you keep your servers clean.  Microsoft seems to have slipped in a hidden requirement to patch the AppController.

You must install .net 3.5.

It isn't required for AppController, but you do need it for the patch.  Without it, KB2887822 starts and just disappears.

To discover this hidden requirement, you can enable command line debugging on the patch.

msiexec.exe /p (path_to_patch) /l*v (path_to_log)

This will run and fail, but you'll now have a log.  Fire up your favorite text editor and open the log.  Do a search for "Value 3" (which, by the way, will appear a few lines after every error in an installation log) and you should see something like this:

MSI (s) (40:00) [15:05:06:499]: Hello, I'm your 64bit Elevated custom action server.
SFXCA: Extracting custom action to temporary directory: C:\Windows\Installer\MSI6EF4.tmp-\
SFXCA: Failed to get requested CLR info. Error code 0x80131700
SFXCA: Ensure that the proper version of the .NET Framework is installed, or that there is a matching supportedRuntime element in CustomAction.config. If you are binding to .NET 4 or greater add useLegacyV2RuntimeActivationPolicy=true to the element.
CustomAction FixArpRegistryKeyPermissions returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
MSI (s) (40:7C) [15:05:06:530]: Note: 1: 2265 2:  3: -2147287035 
MSI (s) (40:7C) [15:05:06:530]: User policy value 'DisableRollback' is 0
MSI (s) (40:7C) [15:05:06:530]: Machine policy value 'DisableRollback' is 0
Action ended 15:05:06: InstallFinalize. Return value 3.

I had .net 4.5 installed, so it was obvious that I needed .net 3.5.

Very poor design that the installer didn't require it, but the patch did, and neither gave me an error when it wasn't there.

Once installed, I was able to apply the patch and continue my upgrade.