Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Server RDP 1
- Thread starter Conno
- Start date
-
1
- #2
VictoriaYudin
IS-IT--Management
The short answer is yes. The longer answer is that you'd have to be running and be licensed for Terminal Services on that server and have installed GP in the proper way. There is a KB article with a lot more detail on this called 'How to deploy Microsoft Dynamics GP and Microsoft Business Solutions - Great Plains in a Terminal Server environment':
Victoria Yudin
Dynamics GP MVP 2005 - 2008
Flexible Solutions - home of GP Reports
blog:
Victoria Yudin
Dynamics GP MVP 2005 - 2008
Flexible Solutions - home of GP Reports
blog:
- Thread starter
- #3
VictoriaYudin
IS-IT--Management
Citrix should be pretty much the same as TS, but with some (possibly) added benefits for larger installations. Not sure what 2X is...? As far as the performance degradation....is it just everything across the board? Something in particular? What changed right before you started seeing it?
Victoria Yudin
Dynamics GP MVP 2005 - 2008
Flexible Solutions - home of GP Reports
blog:
Victoria Yudin
Dynamics GP MVP 2005 - 2008
Flexible Solutions - home of GP Reports
blog:
- Thread starter
- #5
2x is a Citrix like solution. It works in conjunction with MS TS. We loaded GP on 2 virtual server (running of VMWare)and they connect to one SQL server (SQL server is not virtual). 2X helps us load balance between these two servers. It users to one or the other server based on which server is using more/less resources. Our office connection to these servers is through a 100 Mb line. The users are logging under their own (local server) profiles. This solution had worked excellently for us for at least 5-6 months. All of a sudden we are seeing noticeable slowness. When accountants are doing reports (print to screen), you can see report generate on their screens line by line. Printing is also the same. 1 or 2 pages at a time with a lot of lag time in between. We also have installed MS office on these two servers (to work with GP under these users' profiles). However, when we launch an office app. from the servers (and not through GP), it launches very fast, prints very fast as if it is on another machine. So this has got me baffled. We have GP also installed on the SQL server and did a test launch on that server. Everything ran lightning fast. The way I have setup printing is, network printers are setup for each user under his/her profile on each server. User profiles are local to these servers. (no roaming profiles)
VictoriaYudin
IS-IT--Management
Let me just start by saying it's extremely difficult to troubleshoot this kind of stuff without a whole lot more information. And networking, etc. is not my expertise, I am much more knowledgeable on the application side...
However, the first question I have from what you wrote...is it only printing (whether to screen or printer) in GP that's slow? Everything else in GP is ok? Lookups? Posting? Scrolling? If it's just printing, was a new printer or new printer driver introduced into the mix recently?
Other areas to start troubleshooting:
- Is the slow performance experienced when only one of a few users are in the system? Or only at the peak usage times?
- Does logging into the Terminal Server as a local administrator (as opposed to a typical Windows user) make any difference?
- If you are directly on the SQL server, does GP behave the same way?
- If you have a shared reports.dic with modified reports somewhere on a network share, try putting it locally on each virtual server - does that make any difference when printing reports?
For what it's worth.....You don't mention what version of GP you're on, but...to my knowledge, no version of GP is supported on VMWare at this point. GP 10.0 is the only version so far that is supported on anything virtual. I obviously didn't know about 2X - it looks like it adds some pretty neat functionality, but I personally have not heard of anyone using it with GP...I would recommend checking with GP Support to see if they have any experience with 2X, they might have some additional information for you.
That said, internally we've been running GP in virtual environments for testing and development for many years and many versions with no issues. However, we're not running this in production environments with multiple users accessing all the time. Typically the virtual machines get turned off when not needed.
At the end of the day, Microsoft is most likely not going to support this kind of configuration for a production environment. So you may have to take the virtual servers out of the equation to troubleshoot this if nothing else works.
Victoria Yudin
Dynamics GP MVP 2005 - 2008
Flexible Solutions - home of GP Reports
blog:
However, the first question I have from what you wrote...is it only printing (whether to screen or printer) in GP that's slow? Everything else in GP is ok? Lookups? Posting? Scrolling? If it's just printing, was a new printer or new printer driver introduced into the mix recently?
Other areas to start troubleshooting:
- Is the slow performance experienced when only one of a few users are in the system? Or only at the peak usage times?
- Does logging into the Terminal Server as a local administrator (as opposed to a typical Windows user) make any difference?
- If you are directly on the SQL server, does GP behave the same way?
- If you have a shared reports.dic with modified reports somewhere on a network share, try putting it locally on each virtual server - does that make any difference when printing reports?
For what it's worth.....You don't mention what version of GP you're on, but...to my knowledge, no version of GP is supported on VMWare at this point. GP 10.0 is the only version so far that is supported on anything virtual. I obviously didn't know about 2X - it looks like it adds some pretty neat functionality, but I personally have not heard of anyone using it with GP...I would recommend checking with GP Support to see if they have any experience with 2X, they might have some additional information for you.
That said, internally we've been running GP in virtual environments for testing and development for many years and many versions with no issues. However, we're not running this in production environments with multiple users accessing all the time. Typically the virtual machines get turned off when not needed.
At the end of the day, Microsoft is most likely not going to support this kind of configuration for a production environment. So you may have to take the virtual servers out of the equation to troubleshoot this if nothing else works.
Victoria Yudin
Dynamics GP MVP 2005 - 2008
Flexible Solutions - home of GP Reports
blog:
- Thread starter
- #7
Sure, completely understand. This type of trouble shooting is pretty difficult. GP in general seems to be running much slower.
I cut and pasted responses to your questions below.
- Is the slow performance experienced when only one of a few users are in the system? Or only at the peak usage times? Performance is generally slower. Each server is more than capable of handling all of our users by itself. This I know firsthand by running our entire GP environment off of just one for a couple of weeks.
- Does logging into the Terminal Server as a local administrator (as opposed to a typical Windows user) make any difference? This really doesn’t, because in order for each user to successfully use GP in this environment, they are members of the local admin group of each server. Personally, I don’t like this, but I haven’t been able to find setting with lesser rights that works.
- If you are directly on the SQL server, does GP behave the same way? No, it is lightning fast.
- If you have a shared reports.dic with modified reports somewhere on a network share, try putting it locally on each virtual server - does that make any difference when printing reports? I am not sure of this, but am willing to bet that it ISN’T on a network share.
I believe we are running version 9 and are currently looking to upgrade to 10. We try to reboot the servers at least once a week. I keep a pretty good eye on the size of user profiles. So far it has been OK.
Thank you for all your input so far.
I cut and pasted responses to your questions below.
- Is the slow performance experienced when only one of a few users are in the system? Or only at the peak usage times? Performance is generally slower. Each server is more than capable of handling all of our users by itself. This I know firsthand by running our entire GP environment off of just one for a couple of weeks.
- Does logging into the Terminal Server as a local administrator (as opposed to a typical Windows user) make any difference? This really doesn’t, because in order for each user to successfully use GP in this environment, they are members of the local admin group of each server. Personally, I don’t like this, but I haven’t been able to find setting with lesser rights that works.
- If you are directly on the SQL server, does GP behave the same way? No, it is lightning fast.
- If you have a shared reports.dic with modified reports somewhere on a network share, try putting it locally on each virtual server - does that make any difference when printing reports? I am not sure of this, but am willing to bet that it ISN’T on a network share.
I believe we are running version 9 and are currently looking to upgrade to 10. We try to reboot the servers at least once a week. I keep a pretty good eye on the size of user profiles. So far it has been OK.
Thank you for all your input so far.
Howzit
We have GP 9.0 on a SQL Server 2000 (shortly to be upgraded to SQL2005. All our users access GP and FRX via two Citrix boxes (load balancing).
Our two Citrix boxes and the SQL box are both in Cannock, and the users access it from Glasgosw, London Mauritius and Spain with no performance issues - possibly due to all 3 servers being in the same building as opposed to different cities.
We don't allow any of our users to RDP direct to the servers or have a local install of GP on their Desktop \ laptop. This cuts down on needless network traffic.
I have never seen the problem you are experiencing on our set up - and we have had our setup like this for two years now.
Take it Easy
Man with one chopstick go hungry
We have GP 9.0 on a SQL Server 2000 (shortly to be upgraded to SQL2005. All our users access GP and FRX via two Citrix boxes (load balancing).
Our two Citrix boxes and the SQL box are both in Cannock, and the users access it from Glasgosw, London Mauritius and Spain with no performance issues - possibly due to all 3 servers being in the same building as opposed to different cities.
We don't allow any of our users to RDP direct to the servers or have a local install of GP on their Desktop \ laptop. This cuts down on needless network traffic.
I have never seen the problem you are experiencing on our set up - and we have had our setup like this for two years now.
Take it Easy
Man with one chopstick go hungry
- Thread starter
- #9
Our setup is similar. Our GP and corresponding SQL server reside in a colocation center. We use 2X software (instead of Citrix) in order to access these 2 servers. Our setup was doing very well and all of a sudden it took a sharp turn. So I am almost convinced it is not the setup itself, but something else.
VictoriaYudin
IS-IT--Management
Can you think of anything else that was changed between the times everything was working fine and now? It seems that for things to suddenly change, something had to happen.... Another application being installed? Something else using up resources?
Victoria Yudin
Dynamics GP MVP 2005 - 2008
Flexible Solutions - home of GP Reports
blog:
Victoria Yudin
Dynamics GP MVP 2005 - 2008
Flexible Solutions - home of GP Reports
blog:
- Thread starter
- #11
OK. Issue resolved
Recently we installed VoIP system. This required an upgrade to our switches. We installed new Cisco PoE switches. The vendor that had this configured for us, included 'voice-traffic' related rules on the switch that was installed at the Colocation site. This went undetected until we installed our IP phones. In hind sight it is easy to point back to that, but it certainly wasted a lot of our time trying to figure out. I'll be posting the commands online later today, so you can avoid them on your systems. This had slowed us down to 1/12 of our speed and seriously hindered the connection speed between our GP servers and their corresponding SQL server.
Recently we installed VoIP system. This required an upgrade to our switches. We installed new Cisco PoE switches. The vendor that had this configured for us, included 'voice-traffic' related rules on the switch that was installed at the Colocation site. This went undetected until we installed our IP phones. In hind sight it is easy to point back to that, but it certainly wasted a lot of our time trying to figure out. I'll be posting the commands online later today, so you can avoid them on your systems. This had slowed us down to 1/12 of our speed and seriously hindered the connection speed between our GP servers and their corresponding SQL server.
VictoriaYudin
IS-IT--Management
Wow! Thanks for the update and glad you got that resolved!
Victoria Yudin
Dynamics GP MVP 2005 - 2008
Flexible Solutions - home of GP Reports
blog:
Victoria Yudin
Dynamics GP MVP 2005 - 2008
Flexible Solutions - home of GP Reports
blog:
- Status
Similar threads
- Locked
- Question