Forgot to mention. Resource monitor seldom shows more than 4gb of the 10gb
memory being used - but that's not during the slowdown. I've never been
able to see it during the slowdown.


On Wed, Oct 10, 2012 at 11:02 AM, Tom Jedrzejewicz
<tomjedrz@xxxxxxxxxxxxxx>wrote:

I work for a managed services firm. The tech types *hate* this stuff but
the bean counters love it. I suggest you call and have a heart-to-heart
with someone senior there and ask for their most senior engineer to deal
with this at a significantly reduced rate to deal with this issue. If the
response is ... "sorry, our rates are our rates", I would look to replace
them. Also make sure they have fairly specific things to do. If they are
in over their heads, tell them to call Microsoft, but be clear that you
aren't paying for their sitting on hold or their learning. They are
supposed to know this stuff.

Regarding the technical stuff ... it sounds like the RDP server is a VM on
a Hyper-V host. This is a good architecture, although I lean more towards
VMware today. You mention that you looked at the Hyper-V host. Have you
checked the performance of the VM itself? It is possible that the VM may be
set with resource caps (Memory, disk, CPU) that are kicking in. Are there
any other VMs on the Hyper-V host? When the problem is happening, can you
get to the guest through the Hyper-V management console rather than through
RDP?

This smells like a network problem to me. Check the host network
configuration and the host and gust network performance. The host should
have several network ports bonded together on the host and on the (high
quality) switch to increase network capacity for the guests, and a separate
network connection for the host.

Other things to check:

** make sure the HOST anti-virus is not scanning the VM files;

** check the manufacturer hardware management software (HP System
Management, Dell OpenManage, etc.) on the HOST;

** confirm that you have enough Terminal Services licenses.

My suggestion: get more memory for the VM host (10GB for 10 sessions is too
low). Go to at least 24GB ... better 32GB. This may resolve the problem by
itself. If it doesn't, build a new VM, and have some of the clients RDP to
the new one instead of the current one. See what happens. This should
provide enough data to resolve the problem.

I would be happy to talk to you offline about MSPs and such.

Good luck.

---------
Tom Jedrzejewicz
tomjedrz@xxxxxxxxxxxxxx

"Illegitimi non carborundum"



On Wed, Oct 10, 2012 at 7:17 AM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx
wrote:

All,

We have 10 thin clients running RDP to a virtual server, RDS. RDS is
running Windows Server 2008 R2 Standard x64, has 10gb memory, and the C:
drive is 255gb, using 34gb. The thin clients are XP embedded from 10ZiG.
RDS has no domain controller responsibilities, whatsoever. It's only
function in life is to serve the thin clients.

Every so often the thin client users experience a slowdown because the
server, RDS, is busy doing . . . something. What that "something" is, is
the unknown. The thin client sessions, for all practical purposes, come
to
a complete stop. Then, 5-10 minutes later, everything is fine and away
we
go. It typically happens 2 or 3 times a week. No discernible pattern.
Might happen 3 days in a row, then not again for a week. Seems to be
more
often in the morning as opposed to the afternoon. If I look at Hyper-V
at
the time it's happening, Hyper-V says the CPU utilization is 10-12%,
which
doesn't seem excessive to me. But I can never get logged on because of
the
slowdown. A frustrating issue for all involved.

Each of the thin clients will be running 1 or 2 System i sessions and a
browser (either Chrome or Firefox) as we use Google Apps for business.
Individual thin clients _might_ have Excel, Word, Publisher, stuff like
that open.

Since I am a one-person shop responsible more on the business side than
the
tech side these days, we have a Managed Services contract with a company
to
handle these sorts of things. For whatever reason, they cannot figure
out
the issue. The only idea they have had so far is Group Policy update,
but
have since ruled that out.

Nor do they seem to have resources available to them to resolve issues
when
they can't. (That lack of resources on their part is something I will
have
to deal with in the near future.) Their next step is to shotgun it by
analyzing everything in sight at my expense. They want to involve MS,
and
the thin client manufacturer, and do some network routing analysis. They
expect all this to cost me 20-30 hours of billable support. And have
already said if this doesn't resolve it, they'll look at other things.
You
can imagine my joy at this.

Does anybody have any ideas on what I might look at as being the cause of
the slowdown? Both the support company and I have looked at the Windows
logs to no avail.

Thanks.


--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.
--
This is the PC Technical Discussion for iSeries Users (PcTech) mailing
list
To post a message email: PcTech@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/pctech
or email: PcTech-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/pctech.


--
This is the PC Technical Discussion for iSeries Users (PcTech) mailing list
To post a message email: PcTech@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/pctech
or email: PcTech-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/pctech.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.