 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Server Forum / Windows 2000 / Terminal Services / September 2006Application INI not moving to Users Home Directory
We have an application called FSP, that has been working fine on our Terminal server. We installed the latest round of windows security patches and fixes, did a reboot and now we are having problems with it. (Odd thing is it is just this one app, everything else seems to work fine.) What is happing is the application uses an INI file to keep track of your setting and such. Well it keeps overwriting the same INI file now in the \WINNT dir of the terminal server, not the home dir of the indivdual users. Users see the settings of the person that last logged in, not there own. Any ideas what would break the INI mapping for just one application. Like I said the others seem to work just fine, INI's are created as expected. Thanks, Shelby There have been some more reports of this problem in various forums. It only affects W2K Terminal Servers, not 2003 TS. It's caused by the way MS06-051 fixes the "User Profile Elevation of Privilege Vulnerability" You can use the workaround described under -> General Information -> Vulnerability Details -> User Profile Elevation of Privilege Vulnerability -> Workarounds for User Profile Elevation of Privilege Vulnerability in http://www.microsoft.com/technet/security/bulletin/ms06-051.mspx _________________________________________________________ Vera Noest MCSE, CCEA, Microsoft MVP - Terminal Server TS troubleshooting: http://ts.veranoest.net ___ please respond in newsgroup, NOT by private email ___ =?Utf-8?B?U2hlbGJ5?= <Shelby@discussions.microsoft.com> wrote on 24 aug 2006 in microsoft.public.win2000.termserv.apps: > We have an application called FSP, that has been working fine on > our Terminal server. We installed the latest round of windows [quoted text clipped - 15 lines] > > Shelby Ouch.... we experienced this same issue. On one Win2K Terminal Server, most users are affected and won't allow an application to update an .ini file located in the Documents and Settings\userlogin\windows directory. I certainly hope this registry change will fix this problem. \rant mode on I'd like Microsoft to be aware that this little "problem" has cost our company approx 40 man-hours to fix some immediate items and perhaps even some lost cash since the .ini file points to a credit card process which ceased to work. There was no outward evidence of this until the damage was already done where charges did not go through. It will probably take at least another 32 man-hours to track down these charges, correct the errors and recover the revenue. \rant mode off Let me ask this question: Considering the time we've already invested, might it not be better to re-install Win2K so we don't find some other "gotchas" that might arise. We still have to track all the charges, but at least we would have more confidence in the server performing correctly. At this point we've lost some confidence in the server to handle information correctly. In addition, we have a 2nd TS which turned up some different problems not related to the users. It has lost the ability to even do further MS updates. At this point I don't know if this is related or not, but it's suspicious that this occurred at the same time when the last round of updates were installed. MS tech support gave me a long list of items to examine, but re-installing may be a quicker solution. [Ouch again.... it takes a long time to re-install, enter all the users, etc] ~Joe > There have been some more reports of this problem in various > forums. It only affects W2K Terminal Servers, not 2003 TS. [quoted text clipped - 38 lines] >> >> Shelby "J Porter" <porjoe@hnb.com> wrote on 25 aug 2006 in microsoft.public.win2000.termserv.apps: > Let me ask this question: Considering the time we've already > invested, might it not be better to re-install Win2K so we don't > find some other "gotchas" that might arise. Given the fact that the problem is fully understood and that there is a workaround, I would consider a completely fresh re-install a bit of an overkill. > In addition, we have a 2nd TS which turned up some different > problems not related to the users. It has lost the ability to > even do further MS updates. That's another story. Yes, I'd probably do a fresh install in this case, especially if you have a known good image of the server. _________________________________________________________ Vera Noest MCSE, CCEA, Microsoft MVP - Terminal Server TS troubleshooting: http://ts.veranoest.net ___ please respond in newsgroup, NOT by private email ___ I have tried the workaround suggested and it did not fix the problem for us. Any other ideas of how we might troublehoot this to figure out that the problem might be? Again, thank you very much for you time and efforts. Shelby > There have been some more reports of this problem in various > forums. It only affects W2K Terminal Servers, not 2003 TS. [quoted text clipped - 38 lines] > > > > Shelby Never mind I fixed it. Uninstalling KB917422 fixed the problem. Everything is back to normal now. (Lets get some work done.) Thanks for the help, Shelby > I have tried the workaround suggested and it did not fix the problem for us. > Any other ideas of how we might troublehoot this to figure out that the [quoted text clipped - 46 lines] > > > > > > Shelby There is now a "hotfix" available for Win2K. You must call MS and ask for the hotfix for KB917422. This issue is gonna bite some folks because it's so subtle, it can go un-noticed for some time. > Never mind I fixed it. Uninstalling KB917422 fixed the problem. > Everything [quoted text clipped - 55 lines] >> > > >> > > Shelby |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.