How to resolve the issue: “A website wants to start a remote connection. The publisher of this remote connection cannot be identified.”

Often you receive this message when you try to run your remote applications, even though you have all the certificates in place and they are configured properly. You might ask “I have already signed my application with the trusted certificate and my web single sign-on (SSO) is working fine, so why I am receiving this error message?”

The answer: Although you have signed in the application by using the trusted certificate, the client computer needs the Secure Hash Algorithm 1 (SHA1) certificate thumbprints that represent trusted Remote Desktop Protocol (RDP) file publishers.

There are two ways that you can configure your computers so that you don’t see this error message again. 

Method 1: Create a GPO with RDP signing settings (permanent fix)

 

You can create a Group Policy object (GPO) by using the following settings from your domain controller and push that policy to all the client computers that are trying to access the remote application.

Locate the SHA1 thumbprint

 

1. To find the SHA1 thumbprint, click Start, click Run, type mmc, and then click OK.

2. On the File menu, click Add/Remove Snap-in.

3. In the Available snap-ins box, click Certificates, and then click Add.

4. In the Certificates snap-in dialog box, select Computer account, and then click Next.

5. In the Select Computer dialog box, click Local computer: (the computer this console is running on), and then click Finish.

6. In the Add or Remove Snap-ins dialog box, click OK.

7. In the Console tree, expand Certificates (Local Computer), expand Personal, and then click Certificates.

8. Double-click the certificate that you want to use.

9. In the Certificate Properties dialog box, on the Details tab, click Thumbprint. The thumbprint number will appear in the box (example: 25 1a 22 02 b3 6d b6 f0 64 0b db 8d b5 4a bb 99 0f bc ed af).

10. Copy the thumbprint number, making sure that you don’t include the space in front of the number, and then click OK. (For example, if the number starts with 74…, start copying from the “74.”)

 

Add the SHA1 thumbprint to the Group Policy setting

1. On the domain controller, open the Group Policy Management Console (GPMC). You can open the GPMC in one of two ways:

• Click Start, point to Administrative Tools, and then click Group Policy Management Console.
• Click Start, click Run, type gpmc.msc and then click OK or press ENTER.

2. Go to the location of the Group Policy setting: | < user>\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client.

 3. In the Settings pane, double-click Specify SHA1 thumbprints of certificates representing trusted .rdp publishers.

4. Click Enabled, and then in the Comma-separated list of SHA1 trusted certificate thumbprints box, enter the SHA1 thumbprint of the certificate that you use for signing your remote applications or RemoteApp programs (i.e., paste the thumbprint number that you copied from the Certificates Properties page), and then click OK.

Note: Make sure that when you paste the number, there isn’t a space in front of it.

 5. After enabling this policy setting on all the client computers, you should no longer receive the error message.

Method 2: Change logon settings (temporary fix)

1. When you log on to the RD Web Access web page, you have an option to choose whether you are on a public or a private computer.

2. Select This is a private computer, and then click Sign in.

3. You will still see the prompt, but this time when the security warning appears, select the Don’t ask me again for remote connections to this computer check box, and then click Connect.

4. The error message should disappear the next time you open the remote application or RemoteApp program.

 note: this post was copied verbatim from the Microsoft terminal services blog located at (http://blogs.msdn.com/b/rds/archive/2011/04/05/how-to-resolve-the-issue-a-website-wants-to-start-a-remote-connection-the-publisher-of-this-remote-connection-cannot-be-identified.aspx)

Creating an MSI transform (.mst) file with Orca

Orca is a tool that allows you to edit an MSI file’s properties. With Orca, you can easily add customized text, add/remove installation screens, or even change certain conditions contained with the original MSI file.
You can download a copy of Orca from: http://www.technipages.com/download-orca-msi-editor.html.
Steps:

1. Open Orca.
2. Open the original MSI. File > Open > Browse to the MSI > Click Open.
3. Start a new transform. Click on the top “Transform” menu, and select “New Transform”.
4. Make changes. Navigate to a table you want to edit, and modify values.
5. Generate the transform file. Click on the top “Transform” menu, and select “Generate Transform”.
6. Save the transform file. Enter in a name for the transform file, and click “Save”.

You should now have a transform file (.mst) that contains the modifications to the original MSI. Keep in mind that the original MSI has NOT been modified. You will have to apply the transform to the original MSI to have the changes take place.

To run the transform:
In cmd, type:
msiexec /i TRANSFORMS=

For example:
msiexec /i orca.msi TRANSFORMS=transformOrca.mst

this post was copied from Tony's TLE blog post (http://tonyle.ca/blog/?p=33)

and re-posted here for my own reference.

Change RDS Work Spaces name

You can change the Workspace name "Work Resources" by using PowerShell:
First import the module RemoteDesktop and then use the following command:
SYNTAX
   Set-RDWorkspace [-Name] [-ConnectionBroker ]  []

Manage Server 2008 from 2012 Server Manager

One of the biggest improvements to Windows Server 2012 is the (almost) all encompassing Server Manager. From any 2012 server you can now manage any other 2012 server through WinRM - but if you add a 2008 or 2008 R2 server to Server Manager, you will get a manageability warning of “Online – Verify WinRM 3.0 service is installed, running, and required firewall ports are open“.

To get this working, there are 3 main steps to perform:
Install Windows Management Framework 3.0, Allow remote server management through WinRM (preferred method is via Group Policy), Create firewall rules.

 1. Install Windows Management Framework 3.0 Go and get the appropriate .msu from here: http://www.microsoft.com/en-us/download/details.aspx?id=34595 Windows Server 2008 R2 SP1 WINDOWS6.1-KB2506143-x64.MSU Windows Server 2008 SP2 64-bit versions: WINDOWS6.0-KB2506146-x64.MSU 32-bit versions: WINDOWS6.0-KB2506146-x86.MSU As you can see, there are some slight caveats. 2008 R2 requires SP1 while 2008 requires SP2 to be installed.

2. Allow remote server management through WinRM There are 2 ways you can do this. I would recommend use Group Policy wherever possible, so go to: Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service > Allow remote server management through WinRM Set it to enabled and if you want it to listen on all addresses, put a * in IPv4 and IPv6 filter boxes. Alternatively, you can run the command “winrm quickconfig” to enable remote access

3. Create firewall rules Do this again through Group Policy, allowing port 5985.

Configure PXE in SCCM 2012 (R2) failing with error 0x80041001

When configuring a DP as a PXE point you might see this line in the distmgr.log file stating SCCM failed to configure PXE. “CDistributionManager::ConfigurePXE failed; 0x80041001″

 Now, in SCCM 2012, config manager itself will usually want to do all the configuring of WDS and creating the RemoteInstall folder on the DP, but may not in all cases be successful.
If you see WDS is being installed, but no RemoteInstall folder and the error above in the log, try the following:

1. Deactivate PXE on DP from the Management Server and choose to not automatically uninstall WDS
2. Uninstall WDS from DP and restart
3. Install WDS from Server Manager and restart
4. Activate PXE on DP.

You should now soon see the RemoteInstall folder being created and boot images that you have specified as PXE bootable will be populated in the SMSImages folder.

Error importing drivers into SCCM 2012 SP1

While attempting to resolve what I thought was a malformed driver, I removed the Intel Chipset driver from SCCM. Upon attempting to re-import the driver again I was presented with this error (found in the DriverCatalog log).

“Import failed as \\server\share\driverpath\* is a Reparse Point that SMS does not support via downloads.                 DriverCatalog  06-03-2013 14:24:23”

It turns out to be a problem when the driver source location is hosted on a Server 2012 platform with data De-duplication enabled. After much googling, I found this post on technet.

"please be aware that you can run into issues with using server 2012 de-dupe.  ConfigMgr does not currently support re-parse points, so if you attempt to import a driver package or something else that has a re-parse point in it, it will fail."

One solution is to delete the files from the package source and re-copy, this will remove the re-parse points from the De-duplication database and allow SCCM to import the driver. 

The other is to exclude any directories that are used as replication parents from the data de-dupe schedule. Package source, Driver source and OS installation/updates sources should *not* be de-duped. It's annoying not being able to de-dupe these folders but it's safer than having driver packages suddenly (and randomly) become corrupted.

It's a shame that SCCM 2012 R2 still doesn't support re-parse points as we were enjoying a 71% de-dupe rate. Maybe in the next version Microsoft will fix this problem.

Fingers crossed !

Office Customisation Tool Adding desktopfolder shortcuts

When adding shortcuts in the Office Customization Tool for the desktop for Word, Excel, Outlook etc, you will get the follow error message, please note that if I look at the pre-configured shortcuts for the start menu, they do not have a Start In folder specified.



So I added the start in folder off: C:\Program files (x86)\Microsoft Office\Office15\
Fine, no problem right? Well by doing so and clicking OK, the OCT tool adds the same string to the Arguments field and if I try delete that and OK it, it comes back when I open it again:



Sure enough, after install when launching the programs with these shortcuts I get error messages starting with:
"Sorry, we couldn't find your file. Is it possible it was moved, renamed or deleted? (C:\Program.doc)"

The solution is quite simple. Delete the arguments string and replace it with a space and the shortcut will function normally.