SCCM 2012 R2 – Application Catalogue Error – Cannot Install or Request Software (Win 7 x64)

Application Catalog error: Cannot install or request software

Possible cause: Some Windows Update/Silverlight update has caused a bug that makes the Application  Catalog/Silverlight plugin to not work through the 64/32-“hybrid” version of Internet Explorer. 64-bit IE starts by default when you click the Application Catalogue in Software Center.


Run the Software Catalog through the x86-version of Internet Explorer, by browsing to C:\Program Files (x86)\Internet Explorer\iexplore.exe

Browse to:

Note: cm01 is your SCCM application catalogue servername and is your domain-name and -suffix.
“CMApplicationCatalog” is the default web site name, and could differ in your environment.

For me this fixed the situation permanently – without needing to run the x86-browser. The Silverlight-plugin somehow was fixed after doing this.

Another cause/solution is described here:


App-V 5: User/Application data not roaming. Connection Groups in a SCCM and RDS-scenario.

Recently I was troubleshooting an issue where App-V 5 packages was deployed via SCCM in a Remote Desktop Session Host-environment; Users was regularly loosing their application settings and Outlook signature when roaming between different Session Host servers.


Consider the following scenario:
App-V 5.0 SP3 client and App-V-packages are used in Remote Desktop with User profiles saved in UPDs (User Profile Disks).
App-V packages are deployed via integration with SCCM.

Two applications are connected together in a “Virtual Environment” through SCCM.
(For some reason Connection Groups are called Virtual Environments when deployed through SCCM)
Application Settings and Outlook-signatures was not saved when user logged off and the next day was logged into another RDS-server.

Outlook was configured to start in one of the applications that was a member of a SCCM-Virtual Environment by using the following /appvve switch:

"C:\Program Files (x86)\Microsoft Office\Office15\OUTLOOK.EXE" /appvve:783F689D-61FF-4267-AKB4-97A349077ACF_83273B33-65A9-4292-8409-62F27AEB9D99

The first UID:
“783F…” = App-V Package ID
The second UID:
“8327…” = App-V Package VERSION ID

When we open a “normal” single App-V application, the User/Appdata specific to the application would be saved in the following location:


So when we publish a new version of the same application, the userdata is saved and fetched in the same folder on all the different RDS Session Host servers.

But when the application is part of a Virtual Environment (Connection Group) – the application saves all Appdata/User Data in the Connection Groups Appdata-folder.


When using App-V in Full infrastructure mode, a connection groups gets a uniqe ID – in the same fashion that a single App-V Package does.

We would think that the same applied when using Connection Groups/Virtual Environments through SCCM, but for RDS session host-scenarios this is unfortunately not the way it works.

Instead, it works like this:

  • Full infrastructure mode: the Connection Group gets a Global unique ID at the App-V Management-server, and all clients/RDS-session hosts share the same path to the Application Data-folders.
  • SCCM-infrastructure mode: The Virtual Environment gets its uniqe ID at the client-side.
    In a RDS Session Host scenario this means that there is a big chance that two servers will create its own unique ID and thus; a unique path to the application data. The other servers will not share the same Appdata-path. In other words, the Virtual Environment ID is not Global.

Unfortunately I have not found a really good solution to these issues when there is a need for using Connection Groups in a SCCM/RDS Session Host-scenario.
The conclusion I have found so far is that you would need to setup another solution for saving application data for these applications.

For example you could make the App-V Packages save all settings in the default physical paths, instead of the virtualized AppData-folder.

An easy solution might be to Sequence the two applications together in a single package, but this defeats the purpose of Connection Groups.

You could also make the application save the settings in the users home-folder, by configuring the application when possible.

The solutions are something that needs to be considered for each application, to see which creates the best outcome.

Has anyone experienced the same issues, and if you have; how have you solved the issues I discuss?


SCCM 2012 R2: Error: Windows could not configure one or more system components

Scroll down to see some possible solutions to this error.

I just ran into the following error while installing Windows 7 on a new batch of Dell Latitude E7250 machines:

“Windows could not configure one or more system components. To install Windows, restart the computer and then restart the installation.”


Info: Logs for errors occuring during this phase of a Windows installation may be harder to find than the standard SCCM-logs. They are located here:

%systemroot%\panther (C:\Windows\panther)


Oddly enough, some machines went through the installation without a hitch, but several others stopped at the error above (!).

I have experienced this problem in the past, and the solutions have varied some. The culprit in these cases have been unsupported/wrong drivers, and removing or changing the driver(s) in question would remove the error. The problem this time was that we knew that the drivers where working, and had been working on several machines.

During troubleshooting I found several cases noting the same error in conjunction with Dell machines, and some information on the Dell Community pages looked promising.

Apparently some Windows 7 drivers require an updated Kernel Model Driver Framework (KMDF 1.11) to work – and the first suggestion was updating KMDF during the task sequence.

Solution #1 – Add KMDF hotfix to Task Sequence :

If the driver causing the problem is not supported by the older KMDF, then try the following:

Remember to swap packagename in the example. I also suggest using a test version of your Task Sequence for trying out fixes for issues.

Solution #2 – update BIOS:

Unfortunately Solution #1 did not work on our machines, so we had to continue troubleshooting.

Since the TS had successfully run on other machines we worked on finding any difference between these machines and the non-working ones. Mental note: check this as the first action next time. 🙂

We noticed that the BIOS-version was different. A03 on the non-working – and A04 on the working machines. Since we used the A04 version of the driver packages from Dell, some drivers would apparently refuse to work with the older BIOS version. All previous machines we had gotten from Dell had A04 BIOS version – and thus was compatible with the A04 Drivers.

By simply updating the BIOS, the problem was gone.

Solution #3 – Use other drivers:

Go through the logs located in %systemroot%\panther and find the corresponding error-message/driver in question.

Try to find a working version of the driver that is causing the issue, or install the machine without this driver alltogether and then try installing the driver at a later time.

Please leave suggestions if you find other solutions to the error/ symptoms.

PowerShell: Connect to Azure VM Remote Session and Auto-import Certificate

Azure VMs that are created with default settings have all necessary remote-session services running. In addition, their PowerShell public port/endpoint is enabled by default. To find your VMs PowerShell-port, browse to the VM in your Azure management-portal and go to “Endpoints”.

Entering a Remote PowerShell Session:

To enter a session – run the following command, and enter your password when prompted.

Enter-PSSession -ComputerName –Port 54321 -Credential -UseSSL

-ComputerName = Name of the cloud service where the VM resides – i.e.
-Port = The port found in your VMs Endpoint: “PowerShell” Public Port.
-Credential = username@domain or domain\username

You will probably get the following message the first time you try to enter a session against a VM in a cloud service:
The Server certificate on the destination computer ( has the following errors: The SSL certificate is signed by an unknown certificate authority (…)
To get the necessary SSL-certificate, open a web browser, and browse to
In our example:

Screen Shot 2015-05-20 at 14.51.47

Find a small lock-symbol by your URL/addressfield, and import the certificate into your Current User > Trusted root certificates store. Note: Sometimes you may need to use another browser than IE for finding/downloading the certificates.

Automate download and import of certificate:
To make the process easier we can automate the download and import of the cloudservice certificate – so we dont need to manually download/import it with a browser.

Note: the following script relies on the Import-Certificate cmdlet which is only present in PowerShell 4.0-> included in Win 8.1/Server 2012 R2 and newer.

#Usage: Insert variables for CloudserviceName, PowerShell Endpoint Port, Credentials for PS-session, and path to where the certificate-file should be temporary saved before import.

# Set Variables:

$CloudServiceName = ""
$CloudServicePort = "54321"
$CertPath =  "C:\Temp"
$Credential = ""

# Download/Create .cer-file:

$CloudService = "{0}:{1}" -f $CloudServiceName,$CloudServicePort
$WebRequest = [Net.WebRequest]::Create("https://$CloudService")
try { $WebRequest.GetResponse() } catch {}
$Cert = $WebRequest.ServicePoint.Certificate
$Bytes = $Cert.Export([Security.Cryptography.X509Certificates.X509ContentType]::Cert)
set-content -value $Bytes -encoding byte -path "$CertPath\$CloudServiceName.cer"

# Import certicate:

Import-Certificate -FilePath "$CertPath\$CloudServiceName.cer" -CertStoreLocation 'Cert:\CurrentUser\Root' -Verbose 

# Start PS-session on VM:

Enter-PSSession -ComputerName $CloudServiceName –Port $CloudServicePort -Credential $Credential -UseSSL


Thanks to Sandrino di Mattia for a nice introduction to the concepts for entering PS-Sessions on Azure VMs:

The scriptlet for downloading the certificate to a .cer-file was found here, where a nice solution by Michael J. Lyon was shared:

PowerShell: Send e-mails w/ autogenerated passwords

This blog post will cover two subjects, step-by-step:
#1 – Creating (semi) random passwords for users – and performing a set Password routine.
#2 – How to send e-mails to a list of users from a PowerShell script.

Sometimes you want to automatically generate passwords for new users – for example for accounts used for an isolated service, or to set temporary first time use passwords in AD for several hundred users at the same time.

Instead of trying to reinivent the wheel i found a function/cmdlet by Tomas Deceuninck that worked really well. You can find the New-RandomPassword cmdlet here:

Note: If you need even more complex passwords i would suggest looking for complex password generator.

After calling this function/cmdlet, you can then use the generated password in a step to set the password – given the method is supported by a PowerShell-cmdlet. For Active Directory we have the Set-ADAccountPassword cmdlet that can help us achieve this:

Example: Create and Set a Random Password in AD
After importing the New-RandomPassword cmdlet – For a user we can do:

$UserOU = "OU=Test OU,OU=Users,DC=Fabricam,DC=com"
$UserPrincipalName = “”
$NewPassword =  New-RandomPassword 8

Get-ADUser -SearchBase $UserOU -Filter {UserPrincipalName -eq $UserPrincipalName} -Properties * | Set-ADAccountPassword -NewPassword $NewPassword -Reset -PassThru | Set-ADuser -ChangePasswordAtLogon $True 

#logging results – so that admin could manually send the password to users.
“$UserPrincipalName” | Out-File .\password.txt -append 
“$NewPassword” | Out-File .\password.txt -append 

This example creates a password with 8 characters/numbers in total, then selects AD-user from the “Test OU”, and sets the password and making the user have to change password on next logon – in the end writing the UPN and Password to password.txt-file.

Setting a new password, and then bulk sending information e-mail to users
To make it more interesting we can also send this password in an e-mail, granted we have the e-mail address of the users.

NB: Goes without saying – but this method of changing password and sending them via e-mail wont work if the users dont have access to the mail with their current password – and thus is not a good method for changing passwords on users current AD/Exchange-account.

Let´s say we have the following scenario:
We have a list of 30 users that all have @contoso e-mail addresses. We have created accompanying user objects for use with a new service hosted in a domain called
To prevent the users from getting access to other accounts than their own, we dont want to use the same standard password for these users. The users will need to receive a mail telling them how to log on to the new service, and what their new password will be. We will send mails from an account in the fabricam-domain called

The list is formatted in a CSV like this:


And so on…

Prerequisites: <The script will need to be run with an account that has the rights to set passwords on the User objects in the Fabricam-domain – and it needs to be run on a server/computer in the domain with the necessary AD-cmdlets available.

First we will need to load the New-RandomPassword function mentioned in the first step. This could be done with dot-sourcing – or simply copy-pasting the function into the first part of the script.

Script for creating and setting passwords – and sending out bulk e-mail:

#We set the credentials used to send the e-mail – in the example its - and password for the account.

$EmailCredentials = Get-Credential
#We import the users from the list:
CSVImport = Import-Csv –Path "c:\temp\UserList.csv" -Delimiter "," -Encoding UTF8 

#We choose which OU in contains the users we would like to change passwords for
$UserOU = "OU=Test OU,OU=Users,DC=Fabricam,DC=com"

#For each user we will get the attributes needed to process the commands
foreach ($User in $CSVImport) {

$UserGivenName = $User.GivenName
$UserPrincipalName = $User.UserPrincipalName
$UserEmailAddress = $User.EmailAddress
$NewPassword = New-RandomPassword 8
#Setting the new password on each object in AD:

Get-ADUser -SearchBase $UserOU -Filter {UserPrincipalName -eq $UserPrincipalName} -Properties * | Set-ADAccountPassword -NewPassword $NewPassword -Reset -PassThru | Set-ADuser -ChangePasswordAtLogon $True 

#Creating and sending e-mail to users EmailAddress

#Setting mail-properties
$From = ""
$To = "$UserEmailAddress"
$Subject = "Your new password for services"
$SMTPServer = ""
$SMTPPort = "587"
# CC can be used to send copy of email to an administrator/helpdesk for password reference:
$Cc = ""
$Attachment1 = "C:\temp\help me.docx"
$Attachment2 = "C:\temp\attachment2.docx"

#Creating the body-text in html. <br> = new line.
$Body = "Hello $UserGivenName, <br><br>"
$Body += "This e-mail contains your user name and first time password for signing into services: <br><br>"
$Body += "User Name and E-mail address is: $UserPrincipalName <br>"
$Body += "Password: <b>$NewPassword </b><br><br>"

$Body += "Regards, <br>"
$Body += "Fabricam Helpdesk <br>"

Send-MailMessage -From $From -to $To -Subject $Subject `
-Body $Body -BodyAsHtml -Encoding UTF8 -SmtpServer $SMTPServer -port $SMTPPort -UseSsl `
-Credential $EmailCredentials -Attachments $Attachment1, $Attachment2

The result will look something like this in the receivers inbox:
Screen Shot 2015-05-08 at 13.46.41

I hope this will be useful for someone. As always: tips and feedback are welcome. Especially if something could be done in better ways – or something is not working.

SCCM 2012 R2: Error: 0x80070057 – Unable to apply OS, target destination not found

sccm0x80070057 Banner

Note: Issue may also affect other versions of SCCM/MDT)

Problem: Task sequence stops with an error 0x80070057 – usually telling that the apply OS-job couldt not find it´s target destination partition/drive.

One cause of this problem is a “…” default value in ImageOSVer in a MDT created Task Sequence. This causes the TS to skip all disk formatting/partitioning tasks, and the disk won´t be ready for OS deployment.

Solution: Change the ImageOSVer to 6.1 for Windows 7/Windows Server 2008 R2 and newer deployments.


Another issue causing the same error is discussed here:

More information:

SCCM 2012 R2: Error 0x80070070 when running Task Sequence Using Boot Media

sccm0x80070070 error - reference2

Note: Issue may also be present in other versions of SCCM

Issue: When you use a different (WinPE) Boot image in your Boot media and the Task Sequence you are trying to run from SCCM, the TSManager will always try to download the WinPE that is used in the Task Sequence. If the process automatically chooses a disk on the machine that is too small (for example a bitlocker BDE-partition) you will get the 0x80070070 error telling you that “There is not enough space on the disk.”

Important: This will also happen if you use a newer version of the WinPE-image in your TS (!), for example with other drivers than those present in the boot media WinPE.

Solution #1: Create a new bootable media that contains the same Boot image that is referenced in the Task Sequence you are going to run.

You can find information about the boot image in your Task Sequence by Right clicking the TS and selecting properties. Go to the Advanced-pane and see which boot image is configured in “Use a boot image”:

Create a new boot image by right clicking Task Sequences in Software Library and choose Create Task Sequence Media > Bootable Media.

sccm0x80070070 error - reference

Solution #2: If you only need to re-deploy a couple of machines, it might be easier to just remove the BitLocker/System reserved-partition with diskpart on these machines.

Start Console by pressing F8 on the keyboard

Type the following into the console:

select disk 0

After this is done, you can start the TS again (without needing to restart the machine) by first closing the open TS-error message (do not close the console-window) and then opening the following executable from the console:

Thanks to Venu Singireddy for helping me on the right track while troubleshooting this issue: