Microsoft's Surface RT: Using existing Windows apps remotely | ZDNet

Mary Jo Foley examines Microsoft's Surface RT: Using existing Windows apps remotely. Think accessing GP via Terminal Server with a Surface RT tablet.

The Dynamics GP Blogster: Terminal Server: Dynamics.exe encountered a problem and needed to close

Mariano had some fun with Terminal Server: Dynamics.exe encountered a problem and needed to close

Weekly Dynamic: Disable Login on Terminal Server

While upgrading, applying service packs or adding ISV solutions sometimes you want to prevent users from accessing a specific terminal server. Here’s how:
Open a command prompt and enter c:\change logon /disable. 
to restore access enter C:\change logon /enable in a command prompt.
[H.T. to Rob Mitchell of I.B.I.S.]

The Dynamics GP Blogster: Default Printer not 'sticking' when running Microsoft Dynamics GP in Terminal Services RemoteApp

Mariano troubleshoots the Default Printer not 'sticking' when running Microsoft Dynamics GP in Terminal Services RemoteApp

Dynamics GP Land: Performance Issues with Dynamics GP on Terminal Server with Mapped Drives

Steve Endow looks at Performance Issues with Dynamics GP on Terminal Server with Mapped Drives.

We’ve run into similar issues, though in at least one case, speed of the WAN the customer was using was the issue. When I’ve seen this we saw significant printing slowdowns and significant performances differences in SmartLists.

Moving the mapped drive to a TS location significantly improved performance.

Weekly Dynamic: Dynamics GP Passwords, Case Sensitive Logins and ODBC Connections

Yeah, the title is a little weird. Here is the background. A client was moving terminal servers. Old server and new server were both pointed to the same Dynamics GP source. Users would log in to one terminal server and everything worked fine. When they logged into the other terminal server, GP would lock and their password needed to be reset. It didn't matter which terminal server a user logged in to, the first one they logged into worked fine, the second one hung and required a password reset to use that terminal server.
I know, what does the terminal server have to do with a GP password?
Well Dynamics GP uses the User ID and the server name in the ODBC connection as part of the hash when encrypting the user password for the first time. In our case, one of the terminal servers had the SQL Server as a fully qualified domain name and one just had the server name. So the weren't exactly the same and it broke the ability to decrypt the password.

This is also why user logins are case sensitive. The ASCII characters are different for upper and lower case letters so different information is passed when encrypting upper case vs. lower case passwords for the first time.

To solve our little problem we made both server names identical in the ODBC setup and then we reset the passwords of the affected users.

Huge thanks to Rob Mitchell of I.B.I.S. for the background behind this. He is the one who actually solved this issue.

Remote Desktop: Cannot copy file: Cannot read from source file or disk

Steve Endow circles back to an issue where copy and pasting files don’t work in Terminal Server. As an side, I’ve seen almost identical error message when policies are in effect on the terminal server to prevent access to local files so there may be more than one possible cause. Check out Steve’s article Remote Desktop: Cannot copy file: Cannot read from source file or disk for more.

Dynamics GP Slow Login on Terminal Server

Patrick Roth is back at Developing for Dynamics GP with a look at Dynamics GP Slow Login on Terminal Server.

Weekly Review: Dynamics GP, Terminal Services, Cut/Copy/Paste

It's actually been a longstanding issue with Dynamics GP that when using it via Terminal Services users sometimes lose their Copy/Paste functionality within TS. The typical advice has been to logout and log back into TS and Copy/Paste is typically restored. On the Dynamics GP Newsgroup, Alicia W. has come up with a better option. Kill the RDPCLIP process and restart it. This reliably fixes the Copy/Paste issue. To make things easier for her users, she put the process in a batch file that looks like this:

tskill rdpclip
start "" rdpclip

That's it. 2 lines in a batch file and problem solved. Thanks for digging that out Alicia and making it available to the rest of us!

This was supposed to be fixed with GP SP 3 but the problem still crops up occasionally in TS even when not using GP so this tip is still relevant. Every so often even this doesn’t work and you have you close and reconnect.

Originally Posted by Mark at 8/18/2008 09:00:00 AM

Resolution for the Issues with the TS RemoteApp Feature and Microsoft Dynamics GP

I see from Amy Walsh over at DynamicsCare that Microsoft has posted a fix for windows popping under the open screen when using the Remote App features of Terminal server. This is a big deal. We’ve had a few clients going live lately who have had to deal with this. It’s difficult enough to put in a new system but when things seem to keep disappearing it’s really frustrating. Thanks for getting this fixed MS.

Making the Dynamics GP User ID field blank on Terminal Servers

At Dynamics GP Land Steve Endow looks at options for Making the Dynamics GP User ID field blank on Terminal Servers.

Weekly Dynamic: GP 10, Terminal Server and Copy/Paste Issues

It's actually been a longstanding issue with Dynamics GP that when using it via Terminal Services users sometimes lose their Copy/Paste functionality within TS. The typical advice has been to logout and log back into TS and Copy/Paste is typically restored. On the Dynamics GP Newsgroup, Alicia W. has come up with a better option. Kill the RDPCLIP process and restart it. This reliably fixes the Copy/Paste issue. To make things easier for her users, she put the process in a batch file that looks like this:

tskill rdpclip
start "" rdpclip

That's it. 2 lines in a batch file and problem solved. Thanks for digging that out Alicia and making it available to the rest of us!

I've also heard that this has been acknowledged as a issue and should be fixed in SP3.

Dynamics GP Named Printers on a Terminal Server

Make sure that you take a look at Dave Musgrave's latest post where he explains the ins and outs of using Named Printers on a terminal server. Dave even links to a GP paper he wrote with step by step instructions. Very nice Dave! I suspect that this will bail be me out of a jam or two in the future.

No Dynamics GP 10 Workflow on Terminal Services

Just a heads up, I spotted this little tidbit in PartnerSource, apparently, there are issues using Workflow in GP10 over Windows Terminal Services. The recommendation is that you don't do it for now.

Technical Information

Workflow for Microsoft Dynamics GP 10.0 may encounter issues when deployed in a Terminal Server environment.
Because of these issues, it is recommended that you do not use Workflow for Microsoft Dynamics GP 10.0 in an environment where Microsoft Dynamics GP 10.0 is deployed to the clients using Terminal Server.  Microsoft is currently working to address the outstanding issues.
This came to me via RSS as a Hot Topic and I wasn't able to get a KB number for it, but there's not much more information in the entry and there doesn't appear to be an entry in CustomerSource yet. At, not one that I find. (hint, hint CS team).
There was no indication that this topic was confidential so I'm going to post it. The PartnerSource Link is here if you're a partner.