Remote Desktop Connection"An internal error has occurred"

Yeah, try googling that.

  

You will find a gazillion posts with a gazillion different solutions.  None of which fit my case….well at least first half gazillion didn’t.

So I’ll add some keywords here to help this pop out to anyone else who has the same problem as me.

Event 5061 audit failure

TsSecKeySet1

The symptoms we were seeing were happening when attempting to access a Windows Server 2012 Enterprise server via RDP from a Windows 10 Professional workstation.  The error was “An internal error has occurred” which based on my Internet research directly translates to the OS sayin, “huh….that’s weird.”

Nothing particularly useful found in the workstation’s Application or System event logs.  Not much in the server’s either.  But, the criminal’s fingerprint was clearly found in the Security event log, with a one to one correlation of attempts and the following events.

Event Id 5061 audit failure.

Cryptographic operation:

Subject:

                Security ID: NETWORK SERVICE

…blah blah blah…

Cryptographic Parameters:

                Provider Name: Microsoft Software Key Storage Provider

                Algorithm Name: UNKNOWN

                Key Name: TSSecKeySet1

                Key Type: Machine key.

Cryptographic Operation:

                Operation: Open Key.

                Return Code: 0x80090016

Everything you need is in that audit failure.

You see, it turns out the real problem here is that the NETWORK SERVICE account on the server does not have access to the key needed to establish a secure terminal services session.  But where the hell do you set those permissions?  In the file system of course  

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

In my case, I turned to a server that was working and just changed the security settings on my bad server to match the good one.  Those were:

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

·         (local)SYSTEM – Full Control

·         (local)NETWORK SERVICE – Read

·         (local)Administrators – Read

Now, since this was very much an exploration versus a procedure, I also modified rights on the 

following file within the MachineKeys folder as well.

                f686aace6942fb7f7ceb231212eef4a4_xxxxx

·         (local)SYSTEM – Full Control

·         (local)NETWORK SERVICE – Read

·         (local)Administrators – Read

Followed this up with a reboot and like magic, all was well.  I suspect there was a single service that could have been restarted to achieve the same affect, but again this was an exploration, not a procedure.

Hope this helps someone else out.

Peace

d.Stutt

App-V Reporting - Start to Finish and Back Again

Technet has this to say about the App-V 5 Reporting flow

1. After the reporting server receives the data from the computer running the App-V 5.0 client, it sends the data to the reporting database.
2. When the database has received and processed the data, a successful reply is returned to the reporting server.
3. After the reporting server receives the successful reply from the database, a notification is sent to the computer running App-V 5.0 client that the data was successfully received.
4. After the computer running the App-V 5.0 client receives the notification that the data was successfully stored in the database, the client empties the current data cache. This ensures that the cache on the client does not contain previously reported data.

Pasted from <http://technet.microsoft.com/en-us/library/jj692560.aspx>

 

Well, yeah that's pretty high level.  And while there are a few nuggets in there that could be useful for troubleshooting, frankly it has the resolution of a 80's video game.

 

 

If we run into problems, we're going to need seriously more detail than this.

What client properties should I be concerned about?

Where are these client cache files?

Where along the path did it fail?

 

A significant place is missing from the overview above.  It's called  the beginning, and to me it seems like a very fine place to start, at the App-V 5.0 Client.

 

 

At the App-V 5.0 Client:

 

What happens here?

 

It's pretty simple really.   In the case of application usage tracking, the user launches a virtualized application, and if configured to do so, the App-V client creates an .xml file with some details about the launch.  The client then reaches out to the reporting server and attempts to pass the .xml data to it.  If the .xml file appears to be annoyingly persistent (over 24 hours), that's a good indicator that something within the overarching process is not working correctly.  It is important to note that regardless of the thorough description above, the .xml file does not immediately go away after the data makes it to the database server.

 

Things to check on the client

The App-V Client must be setup with reporting turned on.

·         Is the .xml file getting created?Get-AppvClientConfiguration

o    ReportingEnabled should equal 1

o    ReportingServerURL must be valid

·         App-V Client creates .xml files when a virtualized application is launched

o    Referenced .xml file is stored in \ProgramData\Microsoft\AppV\Client\Reporting on the client workstation.    Remember you need your admin account to get into that folder, and the file is hidden by default; so if you're command lining it, you may need to whip out that attrib command.

o    The ReportingInterval property reported from the Get-AppvClientConfiguration command

·         Send-AppvClientReport -<url:port>    (manually sends data collected in workstation cache to the reporting server.  You may want to omit the -DeleteOnSuccess parameter  while testing, but remember even if you do not use this parameter the file will not immediately disappear.)

 

At the App-V 5.0 Reporting Server:

 

What happens here
 

The web service hosting your reporting url now picks up the process.  You can tell the web server is doing its job by checking IIS logs.  The default location will be a subfolder of <drive>\inetpub\logs\LogFiles.    In my case, the file name for the log was u_ex<DATE>.log.  You'll find  an entry with a date/time stamp, your workstation IP address POST - <port#> followed by the account used to authenticate with the server (which will probably be a workstation account.)

 

Things to check on the Reporting server
• World Wide Web Publishing Service is started.
• Any services set to start automatically are running (note that the Microsoft .NET Framework NGEN v.xxxxx services are designed such that they will stop if they have nothing to do at the time.)
• Dig through server event logs for any errors.

 

At the App-V 5.0 SQL Server:

 

What happens here

 

The SQL Server takes the data delivered from the reporting server, and stores it in a kind of temporary table for future processing.  In the case of application usage tracking, two of those table names are dbo.UnprocessedCurrentApplicationUsage and dbo.UnprocessedCompletedApplicationUsage.  As the name indicates, application usage data remains in this table until something else happens.

 

That something else, is the execution of the ProcessAppVReportingDataJob, which can be found under SQL Server Agent\Jobs if you are looking at the SQL Server Management Studio.  It is only after successful completion of this job will the actual application usage tables be updated and the workstation .xml file be removed.

 

Things to check on the SQL Server

• Check the application event log on the SQL server for authentication errors.  They should show as coming from the MSSQL SERVICE source.
• Check your SQL server error logs.  Full transaction logs and disk drives are a tragically common source of database outages.
• Check the ProcessAppVReportingDataJob properties.
• Is the job scheduled?
• Are there any alerts or failures?
• Does it run if you kick it off manually?

 

But where are my reports?

 For me, that remains a mystery.  All I have been able to find is that you should be using SQL Reporting Services.  I don't know if that means there are pre-canned reports out there somewhere, or if that means you Reporting Services to gin up your own shiny graphs and charts.