Term Server w2k3 sp1 effects
in [Terminal Services]
|
Prev: How to move 2003 ts licensing server to different hardware
Next: RDP Client 7.0 + Windows XP SP3: Two connection prompts with TS Gateway
From: danb on 17 Mar 2010 23:49 I apolgize in advance if this has been covered. The problem is so complex that I can not seem to query it properly.... This is an old problem that I worked around - but can no longer work around. I had Server 2003 and Term Server running perfect. Along came SP1 and any new user I created would no longer allow me to setup a certain accounting program on the new users. I would get NTVDM errors. So I simply copied the user profiles of legacy users and did all the regedit stuff and I could create new users that way. Then came SP2 and it got worse - new users would not even be able to access exe setup and runtime files across mapped drives. Says I dont have access, but I can do any thing over the mapped drive except run a client setup.exe or fire the .exe for the program......Applied the same old work around. In both cases - If the user is ADMIN it works, but I tried every security combindtion possible and could never resolve it. Something about the newly created users under the SP upgrades is limiting the legacy 16 bit support. Well now I have to create a new Term Server and I need to resolve it. My accounting package said they were not "term server aware"....what ever that means. The accounting package requires a local install and then fires across the mapped drive. With the ntvdm and all I guess it is 16 bit. It is modern and constantly updated, not some ancient stuff. the only thing that it required to work is running the PIF in sep mem space. I have it running great on my Win 7 Pro32 workstations authenticating to the Server 2003 under legacy user profiles. Win 7 is supported as long as it is 32 bit.....so again this is 16 bit software i presume. After the 100 plus hours I have on this problem over the last 5 years....I just wondered if it sounded familiar to anyone. It was flawless on the Original release of Server 2003 and the service packs have degraded it. I don't know for sure from experience, but they say it works just fine on Server 2003 SP2 WITHOUT TERM SERVER ROLE. Great! Does me no good :) Seems the improvement of w2k3 and security updates and all have squeezed me right out of operation. Was hoping some smart person saw a light. Thanks for your consideration. Regards, Dan B.
From: "Jeff Vandervoort" jeffv at jrvsystems dot on 20 Mar 2010 19:09
16-bit? On a Terminal Server? Ewwww. In the same boat here with Sage Timberline, caused in this case by the ancient Pervasive.SQL database software on which it depends. And though it may be updated frequently, if it's 16-bit, it is--by definition--not modern! Have you run Process Explorer to see where you're running into Access Denieds? Perhaps the SP's tightened ACLs. You may need to loosen them up in a few places. (If it's like Timberline, in a LOT of places!) http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx Suggestion: Put any ACL changes in Group Policy Objects so they automatically apply to future terminal servers, including the one you're about to set up, and will override changes made by Service Packs. I doubt the issue is 16 vs 32 bit, but it's almost guaranteed that a program around long enough to have been written as a 16-bit program is not written with today's ACLs in mind. Esp. term server ACLs. And since it runs as an admin, it's pretty much guaranteed to be an ACL problem. And you probably already know this, but as many advantages as 64-bit holds for RDP, stay with x86 for your new RDP server, or your 16-bit software will not run at all. -- Jeff Vandervoort JRVsystems http://www.jrvsystems.com "danb" <u58816(a)uwe> wrote in message news:a52c826588d0d(a)uwe... > I apolgize in advance if this has been covered. The problem is so complex > that I can not seem to query it properly.... This is an old problem that > I > worked around - but can no longer work around. > > I had Server 2003 and Term Server running perfect. Along came SP1 and any > new user I created would no longer allow me to setup a certain accounting > program on the new users. I would get NTVDM errors. So I simply copied > the > user profiles of legacy users and did all the regedit stuff and I could > create new users that way. > > Then came SP2 and it got worse - new users would not even be able to > access > exe setup and runtime files across mapped drives. Says I dont have > access, > but I can do any thing over the mapped drive except run a client setup.exe > or > fire the .exe for the program......Applied the same old work around. > > In both cases - If the user is ADMIN it works, but I tried every security > combindtion possible and could never resolve it. > > Something about the newly created users under the SP upgrades is limiting > the > legacy 16 bit support. > > Well now I have to create a new Term Server and I need to resolve it. My > accounting package said they were not "term server aware"....what ever > that > means. > > The accounting package requires a local install and then fires across the > mapped drive. With the ntvdm and all I guess it is 16 bit. It is modern > and > constantly updated, not some ancient stuff. the only thing that it > required > to work is running the PIF in sep mem space. I have it running great on my > Win 7 Pro32 workstations authenticating to the Server 2003 under legacy > user > profiles. Win 7 is supported as long as it is 32 bit.....so again this is > 16 > bit software i presume. > > After the 100 plus hours I have on this problem over the last 5 years....I > just wondered if it sounded familiar to anyone. It was flawless on the > Original release of Server 2003 and the service packs have degraded it. I > don't know for sure from experience, but they say it works just fine on > Server 2003 SP2 WITHOUT TERM SERVER ROLE. Great! Does me no good :) > > Seems the improvement of w2k3 and security updates and all have squeezed > me > right out of operation. Was hoping some smart person saw a light. > > Thanks for your consideration. > > Regards, > > Dan B. > |