War Story: The Most Important Spooler Hotfix

I'd like to share a recent experience I had with respect to a migration project from NT4 (MF 1.8) to Win2k (MF XP).

I'd like to share a recent experience I had with respect to a migration project from NT4 (MF 1.8) to Win2k (MF XP). I'm presently engaged in a project for a large Fortune 500 insurance company that is in the process of wrapping up their migration. (I know.. NT4 is unsupported, blah, blah.. Anyway, the line of business that I'm contracting for had serious performance problems on the new server build that the enterprise team delivered. Despite the fact that we used to run ~100 users per server on the old quad 500 Mhz/2GB RAM servers, we we're having significantly worse performance on Windows 2000/MF XP using Quad 1.4Ghz/2GB RAM servers. That frankly didn't add up, and the enterprise folks in the Citrix group simply said, "Nothing can be done. The spooler service just doesn't scale as well on Windows 2000." The Microsoft and Citrix engineers that are onsite for this client agreed--a typical response IMHO. Somehow it just didn't make sense to me that hardware that was three times as powerful would perform worse just because it was Windows 2000, so I began scouring the Internet for anything related to the spooler service with high utilization. Obviously it took me a little while to get through the thousands of articles on this topic since it's one of the most frequently reported issues in Terminal Server environments. Anyway, I ran across this Microsoft KB article that turned out to be EXACTLY what was causing our degraded performance: http://support.microsoft.com/?kbid=840371

This issue affects Windows 2000 and Windows 2003 Servers and is a non-public hotfix. (THis means you'll have to call Microsoft to get it.) This hotfix only came out in May of 2004, so people have been living with this issue for some time. Can can tell if you're affected by this issue is one of two ways:

  1. Fire up Perfmon and monitor the CPU usage of the Spoolsv.exe process as TS sessions are logging off. (I usually will throw an Active Sessions counter up there so I can see the correlation between the session logoff and the spooler CPU consumption.) It's normal to see the Spoolsv.exe service spike up upon session logon and logoff, but if it goes to 100% and stays there for several seconds on a TS session logoff, you're probably affected.
  2. Bring up Task Manager and watch the CPU time allocated to the winlogon.exe process for each TS session. If the CPU time of the winlogon processes is measured in minutes not seconds, you're likely affected. NOTE: If your server has only been running for 10 minutes you won't likely see much CPU time allocated to each Winlogon process. Look at your servers that have active sessions all day long as that server likely had tens or hundreds of logoffs during those active sessions.

Essentially, after applying this hotfix you should see the spooler service be MUCH more tame upon a TS session logoff and you should see quite a reduction in the CPU usage of the Winlogon.exe processes for each user session. The issue has to do with the Spooler service communicating with each and every winlogon.exe process to tear down client printer objects.

From my experience with this hotfix, I've seen NO adverse affects on client printing and the environment is humming along better than ever. I consider this a MUST have hotfix for all Terminal Servers I deploy. I hope you consider it the same.

Join the conversation

54 comments

Send me notifications when other members comment.

Please create a username to comment.

Shawn

man you hit it on the head. I have been having a very very similar issue with some servers that I was recently migrating to XP. I will be calling MS to get this hotfix immediately. I too searched long and hard, but gave up after what felt like 500 documents. Dude, you may have saved me some serious troubleshooting time. You rock....thanks for the info!!!!!

Michael Keen
Hewlett Packard
Cancel
For those who do not like calling MS:
The win2k3 version can be downloaded from http://www.pubforum.net :
http://www.station01.com/~pubforum/w2k3/hf/WindowsServer2003-KB840371-x86-ENU.EXE

The win2k version will be uploaded shortly.
Cancel
All you guys should be receiving emails from Citrix that contain the latest MS Patches that affect TS. Slow logoff's, high CPU..etc...most are bugs. Search web, read the forums. People find patches all the time.

I keep a list of bookmarks to KB articles that deal with TS issues. Its my first point of contact. If I see the same issue in a KB Article, I download and test it. 9 time out of 10 it works.

I am actually surprised to see this article....What??? This has never happened to you before. It just a part of supporting TS.
You need to get used to: Checking MS and Citrix for Patches. Talking to other admins, know what issues are out there.

For all the surprised people out there that are amazed about this patch, better check out the following pages:

http://www.citrix4ge.de
http://www.pubforum.net

Have Fun :)

Luke S
Cancel
Thanks Shawn. You will save many not-so-experienced Citrix admin (like me) valuable time. Brian thanks for posting.
Cancel
No problem. Hopefully it solves your issue.

Shawn
Cancel
Luke -

There's two schools of thought out there.

1) Those sys admins that apply every single patch that comes their way because they assume that it'll make their environment more stable.

2) Those sys admins who don't apply patches unless they apply to their particular situation.

I'm part of camp #2. I was bitten by the old IIS SRP1 patch that Microsoft delivered as part of the Code Red / Nimda remediation and watched as servers blue screened themselves upon restart. Granted, it was done in a development environment, but not all admins have a dev environment, etc. I've also seen a situation at a client site where they got all nervous about the US going to Orange Alert and due to the Department of Homeland Security notification that went out to the CEOs of major Fortune 500 companies in the US, the IT staff went on a patching frenzy. The resultant situation in my Citrix environment was HALF of the Citrix servers blue screening (but it didn't occur in the dev environment, it was something that only happened when the servers were under a stress (i.e. normal production load). So no, I'm not a big fan of "Oh hey there's a new hotfix, I'd better apply it". Besides, particularly when it comes to non-public hotfixes, there's a reason why it's not in the service pack. It hasn't been full regression tested, etc. I'm sure that some day that patch will make it into a Windows 2003 Service Pack or Win2k SP5 if they ever are going to release it. But for now, I'll apply things that apply to my environment.

But to each their own. Whatever works for you.

Shawn
Cancel
1) Those sys admins that apply every single patch that comes their way because they assume that it'll make their environment more stable.

Hehe...thats just crazy...

What i was saying was you only install patches if you think it will solve your issues.
But to make you life easier, keep a record of what patches are out there.

If possible, wait till other admins install beta patches before you install them.

Anywho, good find..I know how you feel when you nail a long running issue.

8er
Cancel
Ok, apparently I misread your original comment. Makes sense now.
Cancel
Anybody have a link to the W2K Server version of this hotfix?
Cancel
I've emailed the win2k version off to Dr. Conti (I believe he's in process of getting the actual hotfix from Microsoft - he doesn't trust me :( anyway, it should be posted up at pubforum.net shortly. Otherwise, you can open a support incident with Microsoft to get it for free, or I could email it to you (pm me your email address if you want me to do that).

Also, when commenting on an article, please include the title or URL of the article you are commenting on since the forum doesn't link back to the original article and it's very tough to know what article people are commenting on.

Thanks.

Shawn
Cancel
No, don't add the title.. I'll add this to the forum asap.. I promise!

Brian
Cancel
ORIGINAL: Brian Madden
No, don't add the title.. I'll add this to the forum asap.. I promise!


OK, sorry. I know you said you were going to do this, didn't mean to be pushy...

Shawn
Cancel
Just mail the win2k version of the hotfix to me, and i will host it untill Dr Conti get's his act together. Stefan@printingsupport.com
Cancel
Done. YHM.
Cancel
Thanks Shawn.
http://www.printingsupport.com/tools/Windows2000-KB840371-x86-ENU.ZIP
Cancel
http:
I really like Steven's site. If you don't read it on a regular basis, you should.

Shawn
Cancel
Yeah, he links to us a lot (which is great). And I agree, it's a great site.

Brian
Cancel
I am not an expert, but does the spooler service(amongst others) need to be run 24/7?
Cancel
It needs to be running whenever someone needs to be able to print. If you don't need printing, you can stop it.
Cancel
I used to download MS patches for my Citrix environment from the net. Than I got a problem and I called MS PSS. We found out the problem was fixed in a hotfix... I already had!!! It seems to be the MS regulary changes PSS hotfixes. Officially anybody who have called MS should get a email telling them to download the new version, in practice this does not always work. (I received 1 mail for 23 hotfixes ordered via PSS). I know of 2 which were updated.
Moral, please be aware MS does only do version control internally on PSS hotfixes (even regulary fixes too but that I saw only once). So I always call them for the latest version, which is free but bothersome.
Mike
Cancel
We have been noticing the spooler service keeps stopping daily when using Citrix sessions we have to keep starting the spooler service a few times daily when people try to print within citrix, would this possibly fix that problem ?
Cancel
I doubt that it would fix that issue, but you could certainly try it. If the spooler service is stopping throughout the day you probably have a bad driver running (actually you're lucky the service is just stopping and not blue screening the server). As a short term fix I'd suggest that you set the Print Spooler server to automatically restart in the event of it stopping. You can set that in the Recovery Tab of the Service properties. For a more permanent solution I'd examine which third party drivers you have installed and remove them and replace them with printer mappings or UPD (which should happen automatically once you remove the driver).

Shawn
Cancel
I agree with Shawn. You should also try stopping the print spooler and then deleting all pending print jobs and then restarting the print spooler. I have seen corrupt jobs cause this problem and after deleting them no more problems.
Cancel
http:
It's a little bit newer and also has all the files in a newer version except gdi32.dll then KB840371.

Gary
Cancel
Possibly, but then again it doesn't mention that it supercedes KB840371 so I don't know for sure. It does look like the files included in KB840371 are in it, but I've got a general policy about hotfixes that I only apply ones that are pertinent to specific problems that I'm having. I haven't experienced this "session freezing" that this hotfix mentions so I'll probably wait for SP5 (if they ever release it) before going that route.

Thanks for the info though.

Shawn
Cancel
Hi,

is this hotfix also included in SP1 for windows 2003, since I cannot find it on the fix-list (http://support.microsoft.com/kb/824721). Since the fix is dates april 2004, you would expect it's included.

Franc.
Cancel
Mind that Microsoft edits some hotfixes from time to time and those who received it from Microsoft receive email notifications with download link to the new hotfix. If you downloaded it from a public place you won't ofcourse receive a notification that a newer hotfix version is available.
Cancel
Gee Shawn...looks like the process that the core terminal services team did for you when you were at a business unit doing staff aug for that Fortune 500 insurance company.

In fact Shawn, that looks just like the write up that one of our engineers did. Thank you for taking credit for the work our team did to resolve this issue.

In the future, if you are going to ride off the backs of excellent engineers, you should credit them for it.
Cancel
I WAS the engineer that figured it out.  The core Term Services team had nothing to do with it.  In fact that team (with all their MS and Citrix field engineers at their disposal) had no clue what was going on.  All I heard from them was "Well you know Windows 2000 Term Services just does scale as well as NT4).  I was the one who figured out the issue with the spooler and found the info on the private hotfix.  Perhaps you should get your facts in order before accusing me of discrediting the source of the fix.  BTW, what's with hiding behind the anonymous title?  I didn't.

Shawn
Cancel
I'll corroborate Shawn's follow-up post.  Maybe the wires are being crossed with different enterprise-wide issues and their solutions...  In this case, Shawn discovered and introduced the spooler hotfix.  Additionally, he did the community a service by posting a write-up of the scenario.  Shawn's 1000+ posts on this forum and other contibutions show that making the comment "In the future, if you are going to ride off the backs of excellent engineers, you should credit them for it" was gratuitous and rancorous.
Cancel
<a href="http: <a href="Bextra'>http: <a href="HIV'>http: <a href="Truponin'>http: <a href="PSA'>http: <a href="Malaria'>http: <a href="Viagra'>http: <a href="Viagra'>http: <a href="Viagra'>http: <a href="Viagra'>http: <a href="Viagra'>http: <a href="Cialis'>http: <a href="Cialis'>http: <a href="levitra'>http: <a href="levitra'>http: <a href="Penis'>http: <a href="Meridia'>http: <a href="AbGymnic'>http: <a href="Xenical'>http: <a href="Propecia'>http: <a href="Propecia'>http: <a href="Paxil'>http: <a href="Prozac'>http: <a href="Zoloft'>http: <a href="Yasmin'>http: <a href="Ortho-Tri-Cyclen'>http: <a href="Norvasc'>http: <a href="Plavix'>http: <a href="Cozaar'>http: <a href="Altace'>http: <a href="Zocor'>http: <a href="Lipitor'>http: <a href="Crestor'>http: <a href="Prilosec'>http: <a href="Prevacid'>http: <a href="Nexium'>http: <a href="Allegra'>http: <a href="Claritin'>http: <a href="Zyrtec'>http: <a href="Zyban'>http: <a href="Zyban'>http: <a href="Cipro'>http: <a href="about'>http: <a href="pills'>http: <a href="how'>http: <a href="where'>http: <a href="http: <a href="http:
Cancel
I eat cereal.
Cancel
Is anyone else still having this problem? On my 5 W2k MetaFrame 1.8 SP4 servers the Winlogon.exe process keeps going crazy and using 50% (or 100% of 1 of the 2 processors).
It does seem that is I start to logoff any disconnected sessions that the problem goes away in a few minutes. According to Microsoft the hotfix Shawn mentions is included in the Update Rollup 1 for W2k SP4 http://support.microsoft.com/kb/900345/ which we applied months ago. This problem just started a few weeks ago, it does not happen every day but some days it happens several times on different servers.

Thanks for any ideas anybody migh thave.

Eric

Cancel
Shawn,
 
I didn't post the previous comment, however, the credit should be given to Dave Verbiscar from MS and James West from Citrix. They, along with myself, are the ones that went to the Ohio data center to do live debugs and print spooler process dumps. That work went into building this very hotfix.
 
I had left the company before the hotfix was completed and more then likely the other engineers dropped the ball in rolling it out to the enterprise. The fact that you "discovered" and posted it is after the fact.
 
I do give you credit for you fantastic contributions to the Citrix community, however, don't over-play your hand.
Cancel
ORIGINAL: Guest

I didn't post the previous comment, however, the credit should be given to Dave Verbiscar from MS and James West from Citrix. They, along with myself, are the ones that went to the Ohio data center to do live debugs and print spooler process dumps. That work went into building this very hotfix.

I had left the company before the hotfix was completed and more then likely the other engineers dropped the ball in rolling it out to the enterprise. The fact that you "discovered" and posted it is after the fact.

I do give you credit for you fantastic contributions to the Citrix community, however, don't over-play your hand.


I don't see how I've overplayed my hand here.  I reported an issue to the Enteprise team.  They checked with Microsoft and Citrix who both said they had no idea why it was performing so poorly.  The problem continued for several months at which time I researched and found the private hotfix.  Never did I claim to create the hotfix, nor did I take credit for the troubleshooting of said hotfix.  My only point was that MS and Citrix were engaged on the issue (and to my knowledge had no comment as to the reason for the performance degredation).  I found out about the private hotfix, obtained it on my own, lab tested it to confirm it fixed the issue, and then turned it over to the Enterprise team who implemented it on my recommendation.  I certainly don't claim that you, Microsoft, and Citrix had no hand in it, but the timing of me finding the hotfix, turning it over to the Enteprise team and said problem being fixed that same day after being broken for several months sure does seem to indicate that I "discovered" the solution.  If you seem to believe that you deserve the credit, then I presume that you would have deployed the hotfix without a request from me.  But that wasn't the case.  At any rate, it's totally retarded that this is still being discussed.  I obviously upset several people over the publishing of this info, which was not my concern at all.  My concern was to notify the community of an issue that personally affected me where the local Citrix/Microsoft SEs did not seem to have an idea of what was wrong.  Nothing more.

Shawn
Cancel
ORIGINAL: Shawn Bass

ORIGINAL: Guest

I didn't post the previous comment, however, the credit should be given to Dave Verbiscar from MS and James West from Citrix. They, along with myself, are the ones that went to the Ohio data center to do live debugs and print spooler process dumps. That work went into building this very hotfix.

I had left the company before the hotfix was completed and more then likely the other engineers dropped the ball in rolling it out to the enterprise. The fact that you "discovered" and posted it is after the fact.

I do give you credit for you fantastic contributions to the Citrix community, however, don't over-play your hand.


I don't see how I've overplayed my hand here.  I reported an issue to the Enteprise team.  They checked with Microsoft and Citrix who both said they had no idea why it was performing so poorly.  The problem continued for several months at which time I researched and found the private hotfix.  Never did I claim to create the hotfix, nor did I take credit for the troubleshooting of said hotfix.  My only point was that MS and Citrix were engaged on the issue (and to my knowledge had no comment as to the reason for the performance degredation).  I found out about the private hotfix, obtained it on my own, lab tested it to confirm it fixed the issue, and then turned it over to the Enterprise team who implemented it on my recommendation.  I certainly don't claim that you, Microsoft, and Citrix had no hand in it, but the timing of me finding the hotfix, turning it over to the Enteprise team and said problem being fixed that same day after being broken for several months sure does seem to indicate that I "discovered" the solution.  If you seem to believe that you deserve the credit, then I presume that you would have deployed the hotfix without a request from me.  But that wasn't the case.  At any rate, it's totally retarded that this is still being discussed.  I obviously upset several people over the publishing of this info, which was not my concern at all.  My concern was to notify the community of an issue that personally affected me where the local Citrix/Microsoft SEs did not seem to have an idea of what was wrong.  Nothing more.

Shawn
Cancel
Shawn,
You overplayed your hand with extreme exuberance in this matter. The facts are this - the enterprise team was fully aware of the print spooler issue along with the assigned Citrix Engineer and Microsoft TAM. The issue was tracked and a trended to determine the full impact to a single server as well as to each silo in the company (this includes the small silo with the handful of applications that you supported). A joint effort between these three teams aided in developing the private hotfix that you stumbled upon after the efforts of this resolution team were completed for months. As to why the  silo you utilized was not patched is an easy answer - you whined every time one the servers that your applications were published on were patched. You used a common consulting practice to try to ingrain yourself by talking down employees of the company to your immediate management.
 
The end result was that we stopped pushing hotfixes to these servers and only applied security fixes (which you still whined about). So, to deal with you, we waited for you to ask for the fixes. Then happily pushed patches to the servers. This is a common practice with staff aug contractors who think they know better than everyone else.
Cancel
Guest, this is such a childish accusation, especially when the original post you commented on was posted 6 months ago.  Based on what I have read, Shawn found the hotfix and brought it to your attention.  You stated you and your team developed the hotfix, knew it was available and then did nothing about it, even when you knew your environment was affected and had a hotfix to fix the problem?  That is the most rediculous argument I have ever heard.

You are just trying to paint Shawn in a bad light because you have some sort of beef with him.  Get off it, already.  Shawn went through the trouble of writing the article on his own time to benefit the community.  You just want to rock the boat and take credit away.
Cancel
Notice again how they are afraid to post who they are.  They are more than brave when they can hide, but you'd never see these comments if there was no 'guest' account.
Cancel
Not afraid at all, I just don't login often and I'm not into self promotion. If you must know, my name is Kevin Buchaniec.
 
You're right; it's childish to keep posting on this thread. However, I just happened upon it just the other day while dealing with printing issues at a client site and found some of the comments interesting.
 
As I had said. I'm not looking for credit, I didn't write the hotfix. Although it was built based on information that I had gathered through spooler process dumps and capturing live debug data; which is wholly irrelevant. Shawn threw this write up for the community, which is great. Forgetting the hotfix number, I even found it useful with my present engagement. However, being the "enterprise engineer" mentioned in it as well as some of the follow-up comments, I didn't appreciate being painted as a misfit so that somebody can self promote themself. I also didn't agree with the fact that nothing was being done but giving lip service. The fact is, the fix took a while create and I had left the company before it was completed. Shawn's contributions to the Citrix Community are great and should be recognized and credited (although, having worked with him in the past, I think making him a CTP is a bit of a stretch - IMHO).
 
Yes, it's stupid to beat this long dead horse, and post more on it.... but I'm sure I won't be the last. 
Cancel
Well hello Kevin.  Nice to finally have confirmation of who is behind the comments (not that it was a stretch to figure out).

Let's review then, shall we?

FACT:  Though you say that you had this hotfix for months, but just didn't roll it out because I whined about the fixes, yet within days of me sending the hotfix over to your team it was rolled out Enterprise-wide.  Prior to me obtaining it, it had not been deployed anywhere.  That seems like an odd coincidence, no?

FACT: Though I don't believe I ever whined about hotfixes, it's not like there wasn't reason for concern.  a) We ran an annuities trading application with several million dollars at risk during unplanned downtime.  It was significantly more important than someone losing a telnet session.  b) Through the work of your team with the monster Orange Alert hotfixes, we found half of our server farm randomly BSOD'ing that following morning (that half that was BSOD'ing was the half that you patched).

FACT:  Though you seem eager to sling mud at me and argue that me being a CTP is a stretch, you seem to make no references to the ACE work that you accomplished at that company such as the "Print Driver Script" that you created to re-install all native print drivers on Windows which you pushed to every Citrix server in the enterprise (one of which happened to be the print driver replication master, which in turn triggered a 1200 driver by 100 server IMA driver replication which quickly brought the entire farm to it's knees for a period of several days - not entirely sure why IMA just wasn't restored, but that's water under the bridge).  Interestingly enough, the consulting firm that designed the farm (yes, the same one you work for now) clearly stated that auto-driver replication was enabled in the farm and they also stated warnings about deploying too many drivers via this auto-replication method.  Lucky for us, we only had 1 non-mission critical app in the Enterprise farm at that time so we weren't drastically impacted.

It's sort of like the old saying "People in glass houses shouldn't throw stones".  Things could have been left well enough alone a long time ago and no one would have known about the great backs of the engineers that I've ridden on.

Shawn


Cancel
Who has the popcorn? More please.
Cancel
ORIGINAL: Guest

you whined every time one the servers that your applications were published on were patched.

You used a common consulting practice to try to ingrain yourself by talking down employees of the company to your immediate management.

The end result was that we stopped pushing hotfixes to these servers and only applied security fixes (which you still whined about). So, to deal with you, we waited for you to ask for the fixes. Then happily pushed patches to the servers.

This is a common practice with staff aug contractors who think they know better than everyone else.


Shawn doesn't think he knows better than everyone else.  (He does know better than a lot of people though.)  To say that is a common practice of staff aug contractors- that's either to minimize Shawn's role (which was that of a consultant - more than staff aug) or to say that this is a common practice of consultants could be implicating of a lot of people here.  Same with the idea about talking down employees as a common consulting practice. Whose "common consulting practice" guidelines are we talking about?  Like Dale Carnegie says in HTWFAIP,  no one should ever speak poorly of anyone else, and I can't imagine a consultant becoming truly successful by talking bad about employees at his/her customers and using some smoke and mirrors w/ technology.

Said patches (lots of bundeled hotfixes) did break the servers.  This did affect business.  If memory serves, there was no option for the biz unit but to install patches in bulk to prod servers on mandated schedules.  We predicted that applying several packaged hotfixes could cause problems, and had no option but to receive the patches.  To call  our response to this whining seems to me to miss a fundamental understanding of what our job is - to provide applications and data to people who show up and want to just do their job.  If someone does something that prevents me from providing that service, then expect that I will "whine" (read: be involved) in a response and in the future.  Whining also implies that we would have just said "no patches, wah" and not proposed solutions for we could keep the servers up to date without having to get intermittent enterprise-mandated bulk patches. Saying things to Shawn like "So, to deal with you..."  Does this mean that we should all put our personal relationships, likes and dislikes, over the technology decisions we make for the customers we provide service to and the workers we provide applications to? 

In one post it says "a small business unit with a handful of apps."  There's over 1000 concurrent users each day, which isn't huge, and makes up 20% of the company's overall Citrix usage.  Even so, like Shawn said w/r/t millions per hour, if this is how the business unit/company does it's business, I don't think one can try to minimize the value based on relative size or perceived complexity.

As far as whether or not any one person should be a CTP.  One can't make categorical statements like that without sharing the decision-criteria that makes him/her see it that way. 
Cancel
I only posted the comments on 8/15/2006 10:10:36 AM and 8/17/2006 12:10:06 PM, not the others. I never slung mud at you or attacked you on a personal level, except if you feel that that my CTP comment was one. If you really want to go there, I have a couple of buckets full to throw back. But I won't.

My CTP comments stem from having worked with this technology for quite some time and having followed what most of the other CTPs have contributed to the community; yours is noteworthy, but not to the extent of being made a CTP for it. It goes far beyond posts on various forums and boards. You look at the applications, books and utilities and time put in by others and it just doesn't measure up. Sorry, but this is my opinion. I'm not a CTP, nor am looking to be one. I've mainly lurked on the boards and can honestly say, have helped very few.

It's interesting that you bring up a couple of historical points, or facts...

In your first "FACT", the hotfixes or famed "Orange Alert" patches, was a management decision against all warnings from the business units and enterprise engineers. No need to go there and anybody that has worked with Windows NT 4.0 TSE know that once you have it stable, don't touch it. There were several custom fixes that wouldn't work with others. I recall working around the clock for 5 days just getting servers back up after that package of death was rolled out. It caused everybody grief.

In your second "FACT", you mix together several different items and apply more fiction than fact... it's actually a good segue into your patch article...  I mention this because I doubt it ever made it out the community and makes for interesting reading as well as being a testament to how messed up printing has been.

We had used the print driver script that was posted in the community a few years back to load all drivers that shipped with the OS. This was a common practice prior to the UPD in MetaFrame XP. The problem occurred when that was integrated into the Citrix base build, along with a wtsuprn.inf with 1200 re-mappings, moving to MetaFrame XP FR2 and then expanding the farm. No driver replication was ever setup so I'm not familiar with what you're talking about. That aside, as the farm grew, the drivers created cross relations to every other member server in the datastore. This eventually inflated the database to about 250 MB... for a 200 server farm, that's very disproportionate. Even the LHC got to be about 250 MB and when the ZDC went to read it, everything started failing.. Including the XML service. Citrix turned out a custom fix in few days which required cutting down the number of drivers, remappings as well as recreating the LHC on every server in the farm. In some instances, it would take about 3-5 days for IMA to restart. Very painfull. Really. Anyway, Citrix also had to turn out a custom DSVerify, compatible with FR2 to purge ghost printers in the DS.

This eventually lead into printing performance, which was eventually addressed with this hotfix through print spooler dumps and live debugging. I'm glad that you did alert the enterprise team to get this rolled out as well as post the article. After I had left, they would never had known about it... an email from Dennis Middleton (Microsoft CPR Team Lead in S. Carolina) was more than likely in my old email inbox. But you still mistake my intentions. My beef was with how presented this and how painted the enterprise team (me, being a previous member of), not the fact that you're looking for credit for this fix. I said it before, you brought this to the community and yes, I found it useful a few times at a few different clients.
Cancel
BTW - don't worry. You can stick a hot poker at me soon enough... I have couple of articles that I sent to Ron and then Brian. Maybe he'll post them. Maybe not.
Cancel
ahhh..it's like old times....
 
i'm out of popcorn.  who's got the goobers?
Cancel
  Zocor is a medicine which is used in hyperlipidaemia. It helps to
lower cholesterol and triglyceride in the blood.  
Here you can find the cheapest Zocor. First pack is free!

You can order by Internet free pack of Zocor here:
http://zocor.hav.pl
Cancel
<a href="car'>http: [link=http:
Cancel
Do you have this hotfix for 2003? I have searched everywhere and can not find a copy.
Cancel
i couldn't thank more to the author since this article makes newbies like us much more more precaution about the windows inner process that tends to break randomly
Cancel

Well, at work and posted a question in the forum and accidentally landed in the "War zone" section as the name got the better of my curiosity and ended up reading this outrageous article. Chaps, you all have been doing an amazing job and it's really not worth the time you've put in to explain yourself..

Keep up the good work!

Prashant 

 

Cancel
I was expecting to read horror stories to educate myself and instead was fully entertained by the posts. I don't know about you guys but would like to see these two duke it out (words only) at Briforums Geek Show next year. It reminds me of my days working at HP Tier 3 support. Cheers!
Cancel
Does anyone know if this was fixed as part of the SP2 update??? As usual microsoft doesn't mention this on their page.
Cancel

can we have more threads like this? the comments have really brightened up my dayhey kev you should have told me about this thread.  I'm back from vacation soon so will catch up soon


Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close