Guest Garrett1226 Posted July 3, 2008 Posted July 3, 2008 I am having a terrible time trying to resolve an issue that is braking many of the applications I am serving up to users inside their Remote Desktop session on a Windows 2003 Terminal Server.... File Type associations for certain extensions show up as "unknown" under certain user profiles, even though the server has valid associations already for apps. Seems like, if a user logs into TS from a machine that has never seem an infopath form before and does not know where to associate an XML file to, the profile will not capture the default association from the server and leaves it as an unknown. This is happening for another file type as well, .TIFF. The only fix I have found is to run the assoc command inside the user RD session, then manually make the file type association by selecting an XML file and then selecting the application from the programs list to open it.... THERE HAS TO BE A FIX FOR THIS OR AN EASIER METHOD FOR PUSHING FILE TYPE ASSOCIATIONS ACCROSS 500 USER PROFILES AND 12 TERMINAL SERVERS!!!!!! Any help would be a blessing at this point.. Thanks!
Guest Jeff Pitsch Posted July 3, 2008 Posted July 3, 2008 Re: File Type Associations W2K3 It sounds like you are using roaming profiles and sharing a profile between a uses desktop and a users terminal server session. I'll be honest with you, this is not what you want to do if this is what is actually happening. You will run into situations exactly what your describing. the best case scenario is to take advantage of the tools that Microsoft has given you. In each user account, you can specify a profile and terminal services profile. You can also specify this in Group Policy. I would highly recommend you do this. This way you will fix the problem and avoid other issues such as profile corruption that you will surely see. Workstation profiles are not meant to be used on terminal services hence why this split is given by Microsoft. Too much garbage ina typical workstation profile that you simply do not want corruputing your terminal services impelmentation. Jeff Pitsch Microsoft MVP - Terminal Services "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote in message news:1512CE15-A032-4636-A8AE-FD867B686726@microsoft.com... >I am having a terrible time trying to resolve an issue that is braking many > of the applications I am serving up to users inside their Remote Desktop > session on a Windows 2003 Terminal Server.... File Type associations for > certain extensions show up as "unknown" under certain user profiles, even > though the server has valid associations already for apps. Seems like, if > a > user logs into TS from a machine that has never seem an infopath form > before > and does not know where to associate an XML file to, the profile will not > capture the default association from the server and leaves it as an > unknown. > This is happening for another file type as well, .TIFF. The only fix I > have > found is to run the assoc command inside the user RD session, then > manually > make the file type association by selecting an XML file and then selecting > the application from the programs list to open it.... > > THERE HAS TO BE A FIX FOR THIS OR AN EASIER METHOD FOR PUSHING FILE TYPE > ASSOCIATIONS ACCROSS 500 USER PROFILES AND 12 TERMINAL SERVERS!!!!!! > > Any help would be a blessing at this point.. Thanks!
Guest Jeff Pitsch Posted July 3, 2008 Posted July 3, 2008 Re: File Type Associations W2K3 One thing I forgot to say is that file type associations are set at the machine level and the user level. the user level overrides the machine level which is why you are seeing what you are. This is why, or one of many, many reasons why, it is best to separate your profiles. Jeff Pitsch Microsoft MVP - Terminal Services "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote in message news:1512CE15-A032-4636-A8AE-FD867B686726@microsoft.com... >I am having a terrible time trying to resolve an issue that is braking many > of the applications I am serving up to users inside their Remote Desktop > session on a Windows 2003 Terminal Server.... File Type associations for > certain extensions show up as "unknown" under certain user profiles, even > though the server has valid associations already for apps. Seems like, if > a > user logs into TS from a machine that has never seem an infopath form > before > and does not know where to associate an XML file to, the profile will not > capture the default association from the server and leaves it as an > unknown. > This is happening for another file type as well, .TIFF. The only fix I > have > found is to run the assoc command inside the user RD session, then > manually > make the file type association by selecting an XML file and then selecting > the application from the programs list to open it.... > > THERE HAS TO BE A FIX FOR THIS OR AN EASIER METHOD FOR PUSHING FILE TYPE > ASSOCIATIONS ACCROSS 500 USER PROFILES AND 12 TERMINAL SERVERS!!!!!! > > Any help would be a blessing at this point.. Thanks!
Guest Garrett1226 Posted July 3, 2008 Posted July 3, 2008 Re: File Type Associations W2K3 Jeff, thanks for the quick response... We have a Terminal Services Farm of 11 servers to load balance our 200 concurrent sessions. We are moving to a brick-style environment where we are serving up the entire desktop experience to the end-user. I have login scripts that control application access, mapped drives and printers - all associated to related OU and security group memberships. In a scenario like this, having a TS Roaming profile was almost a must - unless we wanted to manage changes to specific user accounts across 11 server-specific profiles. I have read old 2000 TS blogs suggesting a way to remove the ability for users to update file type associations to their profiles and to push the default associations from the server to each profile, but cannot find any related 2003 referneces that this is the right course or if it even will work. If we do go full brick - there will essestially be no client-side garbage to pass on to the server, right? So, will this cause other problems with file-type associations with even more applications since the brick cannot pass along its table? Any way to remove this ability to update file types on the server for the users AND replicate the default associations down threw the profiles on each server? Thanks! "Jeff Pitsch" wrote: > It sounds like you are using roaming profiles and sharing a profile between > a uses desktop and a users terminal server session. I'll be honest with > you, this is not what you want to do if this is what is actually happening. > You will run into situations exactly what your describing. > > the best case scenario is to take advantage of the tools that Microsoft has > given you. In each user account, you can specify a profile and terminal > services profile. You can also specify this in Group Policy. I would > highly recommend you do this. This way you will fix the problem and avoid > other issues such as profile corruption that you will surely see. > Workstation profiles are not meant to be used on terminal services hence why > this split is given by Microsoft. Too much garbage ina typical workstation > profile that you simply do not want corruputing your terminal services > impelmentation. > > Jeff Pitsch > Microsoft MVP - Terminal Services > > > "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote in message > news:1512CE15-A032-4636-A8AE-FD867B686726@microsoft.com... > >I am having a terrible time trying to resolve an issue that is braking many > > of the applications I am serving up to users inside their Remote Desktop > > session on a Windows 2003 Terminal Server.... File Type associations for > > certain extensions show up as "unknown" under certain user profiles, even > > though the server has valid associations already for apps. Seems like, if > > a > > user logs into TS from a machine that has never seem an infopath form > > before > > and does not know where to associate an XML file to, the profile will not > > capture the default association from the server and leaves it as an > > unknown. > > This is happening for another file type as well, .TIFF. The only fix I > > have > > found is to run the assoc command inside the user RD session, then > > manually > > make the file type association by selecting an XML file and then selecting > > the application from the programs list to open it.... > > > > THERE HAS TO BE A FIX FOR THIS OR AN EASIER METHOD FOR PUSHING FILE TYPE > > ASSOCIATIONS ACCROSS 500 USER PROFILES AND 12 TERMINAL SERVERS!!!!!! > > > > Any help would be a blessing at this point.. Thanks! > > >
Guest Jeff Pitsch Posted July 3, 2008 Posted July 3, 2008 Re: File Type Associations W2K3 Are you using TS roaming profiles right now or the default workstation roaming profiles? there is also a HKCU key for every users and a filetype assocation key for every user (classes root entries). You will always have user registry entries to deal with but with a clean server or a new profile being generated for users they should not have the problem of overriding HKCU keys. If the profile is being reused from workstations then yes this problem is there. If you delete and recreate the users profile does the situation still exist? Jeff Pitsch Microsoft MVP - Terminal Services "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote in message news:373B76C1-19C4-487A-9CCA-8BB34CA36F13@microsoft.com... > Jeff, thanks for the quick response... We have a Terminal Services Farm > of > 11 servers to load balance our 200 concurrent sessions. We are moving to > a > brick-style environment where we are serving up the entire desktop > experience > to the end-user. I have login scripts that control application access, > mapped drives and printers - all associated to related OU and security > group > memberships. In a scenario like this, having a TS Roaming profile was > almost > a must - unless we wanted to manage changes to specific user accounts > across > 11 server-specific profiles. > > I have read old 2000 TS blogs suggesting a way to remove the ability for > users to update file type associations to their profiles and to push the > default associations from the server to each profile, but cannot find any > related 2003 referneces that this is the right course or if it even will > work. > > If we do go full brick - there will essestially be no client-side garbage > to > pass on to the server, right? So, will this cause other problems with > file-type associations with even more applications since the brick cannot > pass along its table? Any way to remove this ability to update file types > on > the server for the users AND replicate the default associations down threw > the profiles on each server? Thanks! > > "Jeff Pitsch" wrote: > >> It sounds like you are using roaming profiles and sharing a profile >> between >> a uses desktop and a users terminal server session. I'll be honest with >> you, this is not what you want to do if this is what is actually >> happening. >> You will run into situations exactly what your describing. >> >> the best case scenario is to take advantage of the tools that Microsoft >> has >> given you. In each user account, you can specify a profile and terminal >> services profile. You can also specify this in Group Policy. I would >> highly recommend you do this. This way you will fix the problem and >> avoid >> other issues such as profile corruption that you will surely see. >> Workstation profiles are not meant to be used on terminal services hence >> why >> this split is given by Microsoft. Too much garbage ina typical >> workstation >> profile that you simply do not want corruputing your terminal services >> impelmentation. >> >> Jeff Pitsch >> Microsoft MVP - Terminal Services >> >> >> "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote in message >> news:1512CE15-A032-4636-A8AE-FD867B686726@microsoft.com... >> >I am having a terrible time trying to resolve an issue that is braking >> >many >> > of the applications I am serving up to users inside their Remote >> > Desktop >> > session on a Windows 2003 Terminal Server.... File Type associations >> > for >> > certain extensions show up as "unknown" under certain user profiles, >> > even >> > though the server has valid associations already for apps. Seems like, >> > if >> > a >> > user logs into TS from a machine that has never seem an infopath form >> > before >> > and does not know where to associate an XML file to, the profile will >> > not >> > capture the default association from the server and leaves it as an >> > unknown. >> > This is happening for another file type as well, .TIFF. The only fix I >> > have >> > found is to run the assoc command inside the user RD session, then >> > manually >> > make the file type association by selecting an XML file and then >> > selecting >> > the application from the programs list to open it.... >> > >> > THERE HAS TO BE A FIX FOR THIS OR AN EASIER METHOD FOR PUSHING FILE >> > TYPE >> > ASSOCIATIONS ACCROSS 500 USER PROFILES AND 12 TERMINAL SERVERS!!!!!! >> > >> > Any help would be a blessing at this point.. Thanks! >> >> >>
Guest Garrett1226 Posted July 3, 2008 Posted July 3, 2008 Re: File Type Associations W2K3 I am using TS Roaming profiles. We removed all login Roaming profiles from our AD schema years ago due to a ton of problems surrounding maintaining/maintenancing them..... So, if I understand right - If I updated the file type associations in the HKCU programmatically thru the Terminal Server login scripts I already have in place, this may be a quick fix for problematic file types and correct any legacy profiles that were incorrect? I have the TS sessions locked down very hard, would this approach require users to have registry access to make this update? Do you see any problems that may occur from 20 plus users concurrently making registry hacks at login? Do you know of any way to remove the user's ability to update file type associations for their profiles going forward if this works? Thanks again! "Jeff Pitsch" wrote: > Are you using TS roaming profiles right now or the default workstation > roaming profiles? > > there is also a HKCU key for every users and a filetype assocation key for > every user (classes root entries). You will always have user registry > entries to deal with but with a clean server or a new profile being > generated for users they should not have the problem of overriding HKCU > keys. If the profile is being reused from workstations then yes this > problem is there. If you delete and recreate the users profile does the > situation still exist? > > > Jeff Pitsch > Microsoft MVP - Terminal Services > > > "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote in message > news:373B76C1-19C4-487A-9CCA-8BB34CA36F13@microsoft.com... > > Jeff, thanks for the quick response... We have a Terminal Services Farm > > of > > 11 servers to load balance our 200 concurrent sessions. We are moving to > > a > > brick-style environment where we are serving up the entire desktop > > experience > > to the end-user. I have login scripts that control application access, > > mapped drives and printers - all associated to related OU and security > > group > > memberships. In a scenario like this, having a TS Roaming profile was > > almost > > a must - unless we wanted to manage changes to specific user accounts > > across > > 11 server-specific profiles. > > > > I have read old 2000 TS blogs suggesting a way to remove the ability for > > users to update file type associations to their profiles and to push the > > default associations from the server to each profile, but cannot find any > > related 2003 referneces that this is the right course or if it even will > > work. > > > > If we do go full brick - there will essestially be no client-side garbage > > to > > pass on to the server, right? So, will this cause other problems with > > file-type associations with even more applications since the brick cannot > > pass along its table? Any way to remove this ability to update file types > > on > > the server for the users AND replicate the default associations down threw > > the profiles on each server? Thanks! > > > > "Jeff Pitsch" wrote: > > > >> It sounds like you are using roaming profiles and sharing a profile > >> between > >> a uses desktop and a users terminal server session. I'll be honest with > >> you, this is not what you want to do if this is what is actually > >> happening. > >> You will run into situations exactly what your describing. > >> > >> the best case scenario is to take advantage of the tools that Microsoft > >> has > >> given you. In each user account, you can specify a profile and terminal > >> services profile. You can also specify this in Group Policy. I would > >> highly recommend you do this. This way you will fix the problem and > >> avoid > >> other issues such as profile corruption that you will surely see. > >> Workstation profiles are not meant to be used on terminal services hence > >> why > >> this split is given by Microsoft. Too much garbage ina typical > >> workstation > >> profile that you simply do not want corruputing your terminal services > >> impelmentation. > >> > >> Jeff Pitsch > >> Microsoft MVP - Terminal Services > >> > >> > >> "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote in message > >> news:1512CE15-A032-4636-A8AE-FD867B686726@microsoft.com... > >> >I am having a terrible time trying to resolve an issue that is braking > >> >many > >> > of the applications I am serving up to users inside their Remote > >> > Desktop > >> > session on a Windows 2003 Terminal Server.... File Type associations > >> > for > >> > certain extensions show up as "unknown" under certain user profiles, > >> > even > >> > though the server has valid associations already for apps. Seems like, > >> > if > >> > a > >> > user logs into TS from a machine that has never seem an infopath form > >> > before > >> > and does not know where to associate an XML file to, the profile will > >> > not > >> > capture the default association from the server and leaves it as an > >> > unknown. > >> > This is happening for another file type as well, .TIFF. The only fix I > >> > have > >> > found is to run the assoc command inside the user RD session, then > >> > manually > >> > make the file type association by selecting an XML file and then > >> > selecting > >> > the application from the programs list to open it.... > >> > > >> > THERE HAS TO BE A FIX FOR THIS OR AN EASIER METHOD FOR PUSHING FILE > >> > TYPE > >> > ASSOCIATIONS ACCROSS 500 USER PROFILES AND 12 TERMINAL SERVERS!!!!!! > >> > > >> > Any help would be a blessing at this point.. Thanks! > >> > >> > >> > > >
Guest Jeff Pitsch Posted July 3, 2008 Posted July 3, 2008 Re: File Type Associations W2K3 Here's one way: http://technet2.microsoft.com/windowsserver/en/library/2955fe3f-747e-46a6-8825-eb9eb7baacae1033.mspx?mfr=true And I'm almost positive there is another way of doing it through GPO or something but mind is drawing a blank. I'm still searching though and will let you know if I find anything. Jeff Pitsch Microsoft MVP - Terminal Services "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote in message news:DC0A24F9-4EBC-4078-8058-4B8AD2D75B62@microsoft.com... >I am using TS Roaming profiles. We removed all login Roaming profiles from > our AD schema years ago due to a ton of problems surrounding > maintaining/maintenancing them..... > > So, if I understand right - If I updated the file type associations in the > HKCU programmatically thru the Terminal Server login scripts I already > have > in place, this may be a quick fix for problematic file types and correct > any > legacy profiles that were incorrect? I have the TS sessions locked down > very > hard, would this approach require users to have registry access to make > this > update? Do you see any problems that may occur from 20 plus users > concurrently making registry hacks at login? Do you know of any way to > remove the user's ability to update file type associations for their > profiles > going forward if this works? > > Thanks again! > > "Jeff Pitsch" wrote: > >> Are you using TS roaming profiles right now or the default workstation >> roaming profiles? >> >> there is also a HKCU key for every users and a filetype assocation key >> for >> every user (classes root entries). You will always have user registry >> entries to deal with but with a clean server or a new profile being >> generated for users they should not have the problem of overriding HKCU >> keys. If the profile is being reused from workstations then yes this >> problem is there. If you delete and recreate the users profile does the >> situation still exist? >> >> >> Jeff Pitsch >> Microsoft MVP - Terminal Services >> >> >> "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote in message >> news:373B76C1-19C4-487A-9CCA-8BB34CA36F13@microsoft.com... >> > Jeff, thanks for the quick response... We have a Terminal Services >> > Farm >> > of >> > 11 servers to load balance our 200 concurrent sessions. We are moving >> > to >> > a >> > brick-style environment where we are serving up the entire desktop >> > experience >> > to the end-user. I have login scripts that control application access, >> > mapped drives and printers - all associated to related OU and security >> > group >> > memberships. In a scenario like this, having a TS Roaming profile was >> > almost >> > a must - unless we wanted to manage changes to specific user accounts >> > across >> > 11 server-specific profiles. >> > >> > I have read old 2000 TS blogs suggesting a way to remove the ability >> > for >> > users to update file type associations to their profiles and to push >> > the >> > default associations from the server to each profile, but cannot find >> > any >> > related 2003 referneces that this is the right course or if it even >> > will >> > work. >> > >> > If we do go full brick - there will essestially be no client-side >> > garbage >> > to >> > pass on to the server, right? So, will this cause other problems with >> > file-type associations with even more applications since the brick >> > cannot >> > pass along its table? Any way to remove this ability to update file >> > types >> > on >> > the server for the users AND replicate the default associations down >> > threw >> > the profiles on each server? Thanks! >> > >> > "Jeff Pitsch" wrote: >> > >> >> It sounds like you are using roaming profiles and sharing a profile >> >> between >> >> a uses desktop and a users terminal server session. I'll be honest >> >> with >> >> you, this is not what you want to do if this is what is actually >> >> happening. >> >> You will run into situations exactly what your describing. >> >> >> >> the best case scenario is to take advantage of the tools that >> >> Microsoft >> >> has >> >> given you. In each user account, you can specify a profile and >> >> terminal >> >> services profile. You can also specify this in Group Policy. I would >> >> highly recommend you do this. This way you will fix the problem and >> >> avoid >> >> other issues such as profile corruption that you will surely see. >> >> Workstation profiles are not meant to be used on terminal services >> >> hence >> >> why >> >> this split is given by Microsoft. Too much garbage ina typical >> >> workstation >> >> profile that you simply do not want corruputing your terminal services >> >> impelmentation. >> >> >> >> Jeff Pitsch >> >> Microsoft MVP - Terminal Services >> >> >> >> >> >> "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote in message >> >> news:1512CE15-A032-4636-A8AE-FD867B686726@microsoft.com... >> >> >I am having a terrible time trying to resolve an issue that is >> >> >braking >> >> >many >> >> > of the applications I am serving up to users inside their Remote >> >> > Desktop >> >> > session on a Windows 2003 Terminal Server.... File Type >> >> > associations >> >> > for >> >> > certain extensions show up as "unknown" under certain user profiles, >> >> > even >> >> > though the server has valid associations already for apps. Seems >> >> > like, >> >> > if >> >> > a >> >> > user logs into TS from a machine that has never seem an infopath >> >> > form >> >> > before >> >> > and does not know where to associate an XML file to, the profile >> >> > will >> >> > not >> >> > capture the default association from the server and leaves it as an >> >> > unknown. >> >> > This is happening for another file type as well, .TIFF. The only >> >> > fix I >> >> > have >> >> > found is to run the assoc command inside the user RD session, then >> >> > manually >> >> > make the file type association by selecting an XML file and then >> >> > selecting >> >> > the application from the programs list to open it.... >> >> > >> >> > THERE HAS TO BE A FIX FOR THIS OR AN EASIER METHOD FOR PUSHING FILE >> >> > TYPE >> >> > ASSOCIATIONS ACCROSS 500 USER PROFILES AND 12 TERMINAL SERVERS!!!!!! >> >> > >> >> > Any help would be a blessing at this point.. Thanks! >> >> >> >> >> >> >> >> >>
Guest Vera Noest [MVP] Posted July 3, 2008 Posted July 3, 2008 Re: File Type Associations W2K3 The problem is documented here: 257592 - Changes in File Types and File Association Features in Windows 2000 and Windows Server 2003 http://support.microsoft.com/?kbid=257592 So you'll have to let the users import a .reg file to create the file associations. _________________________________________________________ Vera Noest MCSE, CCEA, Microsoft MVP - Terminal Server TS troubleshooting: http://ts.veranoest.net ___ please respond in newsgroup, NOT by private email ___ "Jeff Pitsch" <jeff@jeffpitschconsulting.com> wrote on 03 jul 2008 in microsoft.public.windows.terminal_services: > Here's one way: > http://technet2.microsoft.com/windowsserver/en/library/2955fe3f-7 > 47e-46a6-8825-eb9eb7baacae1033.mspx?mfr=true > > And I'm almost positive there is another way of doing it through > GPO or something but mind is drawing a blank. I'm still > searching though and will let you know if I find anything. > > Jeff Pitsch > Microsoft MVP - Terminal Services > > > "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote in > message > news:DC0A24F9-4EBC-4078-8058-4B8AD2D75B62@microsoft.com... >>I am using TS Roaming profiles. We removed all login Roaming >>profiles from >> our AD schema years ago due to a ton of problems surrounding >> maintaining/maintenancing them..... >> >> So, if I understand right - If I updated the file type >> associations in the HKCU programmatically thru the Terminal >> Server login scripts I already have >> in place, this may be a quick fix for problematic file types >> and correct any >> legacy profiles that were incorrect? I have the TS sessions >> locked down very >> hard, would this approach require users to have registry access >> to make this >> update? Do you see any problems that may occur from 20 plus >> users concurrently making registry hacks at login? Do you know >> of any way to remove the user's ability to update file type >> associations for their profiles >> going forward if this works? >> >> Thanks again! >> >> "Jeff Pitsch" wrote: >> >>> Are you using TS roaming profiles right now or the default >>> workstation roaming profiles? >>> >>> there is also a HKCU key for every users and a filetype >>> assocation key for >>> every user (classes root entries). You will always have user >>> registry entries to deal with but with a clean server or a new >>> profile being generated for users they should not have the >>> problem of overriding HKCU keys. If the profile is being >>> reused from workstations then yes this problem is there. If >>> you delete and recreate the users profile does the situation >>> still exist? >>> >>> >>> Jeff Pitsch >>> Microsoft MVP - Terminal Services >>> >>> >>> "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote in >>> message >>> news:373B76C1-19C4-487A-9CCA-8BB34CA36F13@microsoft.com... >>> > Jeff, thanks for the quick response... We have a Terminal >>> > Services Farm >>> > of >>> > 11 servers to load balance our 200 concurrent sessions. We >>> > are moving to >>> > a >>> > brick-style environment where we are serving up the entire >>> > desktop experience >>> > to the end-user. I have login scripts that control >>> > application access, mapped drives and printers - all >>> > associated to related OU and security group >>> > memberships. In a scenario like this, having a TS Roaming >>> > profile was almost >>> > a must - unless we wanted to manage changes to specific user >>> > accounts across >>> > 11 server-specific profiles. >>> > >>> > I have read old 2000 TS blogs suggesting a way to remove the >>> > ability for >>> > users to update file type associations to their profiles and >>> > to push the >>> > default associations from the server to each profile, but >>> > cannot find any >>> > related 2003 referneces that this is the right course or if >>> > it even will >>> > work. >>> > >>> > If we do go full brick - there will essestially be no >>> > client-side garbage >>> > to >>> > pass on to the server, right? So, will this cause other >>> > problems with file-type associations with even more >>> > applications since the brick cannot >>> > pass along its table? Any way to remove this ability to >>> > update file types >>> > on >>> > the server for the users AND replicate the default >>> > associations down threw >>> > the profiles on each server? Thanks! >>> > >>> > "Jeff Pitsch" wrote: >>> > >>> >> It sounds like you are using roaming profiles and sharing a >>> >> profile between >>> >> a uses desktop and a users terminal server session. I'll >>> >> be honest with >>> >> you, this is not what you want to do if this is what is >>> >> actually happening. >>> >> You will run into situations exactly what your describing. >>> >> >>> >> the best case scenario is to take advantage of the tools >>> >> that Microsoft >>> >> has >>> >> given you. In each user account, you can specify a profile >>> >> and terminal >>> >> services profile. You can also specify this in Group >>> >> Policy. I would highly recommend you do this. This way >>> >> you will fix the problem and avoid >>> >> other issues such as profile corruption that you will >>> >> surely see. Workstation profiles are not meant to be used >>> >> on terminal services hence >>> >> why >>> >> this split is given by Microsoft. Too much garbage ina >>> >> typical workstation >>> >> profile that you simply do not want corruputing your >>> >> terminal services impelmentation. >>> >> >>> >> Jeff Pitsch >>> >> Microsoft MVP - Terminal Services >>> >> >>> >> >>> >> "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote >>> >> in message >>> >> news:1512CE15-A032-4636-A8AE-FD867B686726@microsoft.com... >>> >> >I am having a terrible time trying to resolve an issue >>> >> >that is braking >>> >> >many >>> >> > of the applications I am serving up to users inside their >>> >> > Remote Desktop >>> >> > session on a Windows 2003 Terminal Server.... File Type >>> >> > associations >>> >> > for >>> >> > certain extensions show up as "unknown" under certain >>> >> > user profiles, even >>> >> > though the server has valid associations already for >>> >> > apps. Seems like, >>> >> > if >>> >> > a >>> >> > user logs into TS from a machine that has never seem an >>> >> > infopath form >>> >> > before >>> >> > and does not know where to associate an XML file to, the >>> >> > profile will >>> >> > not >>> >> > capture the default association from the server and >>> >> > leaves it as an unknown. >>> >> > This is happening for another file type as well, .TIFF. >>> >> > The only fix I >>> >> > have >>> >> > found is to run the assoc command inside the user RD >>> >> > session, then manually >>> >> > make the file type association by selecting an XML file >>> >> > and then selecting >>> >> > the application from the programs list to open it.... >>> >> > >>> >> > THERE HAS TO BE A FIX FOR THIS OR AN EASIER METHOD FOR >>> >> > PUSHING FILE TYPE >>> >> > ASSOCIATIONS ACCROSS 500 USER PROFILES AND 12 TERMINAL >>> >> > SERVERS!!!!!! >>> >> > >>> >> > Any help would be a blessing at this point.. Thanks!
Guest Jeff Pitsch Posted July 3, 2008 Posted July 3, 2008 Re: File Type Associations W2K3 Hey Vera, I may have gone completely crazy but I would have sworn there was a way to tell windows to ignore the HKCU keys altogether. Jeff Pitsch Microsoft MVP - Terminal Services "Vera Noest [MVP]" <vera.noest@remove-this.hem.utfors.se> wrote in message news:Xns9AD0DF23617F5veranoesthemutforsse@207.46.248.16... > The problem is documented here: > > 257592 - Changes in File Types and File Association Features in > Windows 2000 and Windows Server 2003 > http://support.microsoft.com/?kbid=257592 > > So you'll have to let the users import a .reg file to create the > file associations. > _________________________________________________________ > Vera Noest > MCSE, CCEA, Microsoft MVP - Terminal Server > TS troubleshooting: http://ts.veranoest.net > ___ please respond in newsgroup, NOT by private email ___ > > "Jeff Pitsch" <jeff@jeffpitschconsulting.com> wrote on 03 jul 2008 > in microsoft.public.windows.terminal_services: > >> Here's one way: >> http://technet2.microsoft.com/windowsserver/en/library/2955fe3f-7 >> 47e-46a6-8825-eb9eb7baacae1033.mspx?mfr=true >> >> And I'm almost positive there is another way of doing it through >> GPO or something but mind is drawing a blank. I'm still >> searching though and will let you know if I find anything. >> >> Jeff Pitsch >> Microsoft MVP - Terminal Services >> >> >> "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote in >> message >> news:DC0A24F9-4EBC-4078-8058-4B8AD2D75B62@microsoft.com... >>>I am using TS Roaming profiles. We removed all login Roaming >>>profiles from >>> our AD schema years ago due to a ton of problems surrounding >>> maintaining/maintenancing them..... >>> >>> So, if I understand right - If I updated the file type >>> associations in the HKCU programmatically thru the Terminal >>> Server login scripts I already have >>> in place, this may be a quick fix for problematic file types >>> and correct any >>> legacy profiles that were incorrect? I have the TS sessions >>> locked down very >>> hard, would this approach require users to have registry access >>> to make this >>> update? Do you see any problems that may occur from 20 plus >>> users concurrently making registry hacks at login? Do you know >>> of any way to remove the user's ability to update file type >>> associations for their profiles >>> going forward if this works? >>> >>> Thanks again! >>> >>> "Jeff Pitsch" wrote: >>> >>>> Are you using TS roaming profiles right now or the default >>>> workstation roaming profiles? >>>> >>>> there is also a HKCU key for every users and a filetype >>>> assocation key for >>>> every user (classes root entries). You will always have user >>>> registry entries to deal with but with a clean server or a new >>>> profile being generated for users they should not have the >>>> problem of overriding HKCU keys. If the profile is being >>>> reused from workstations then yes this problem is there. If >>>> you delete and recreate the users profile does the situation >>>> still exist? >>>> >>>> >>>> Jeff Pitsch >>>> Microsoft MVP - Terminal Services >>>> >>>> >>>> "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote in >>>> message >>>> news:373B76C1-19C4-487A-9CCA-8BB34CA36F13@microsoft.com... >>>> > Jeff, thanks for the quick response... We have a Terminal >>>> > Services Farm >>>> > of >>>> > 11 servers to load balance our 200 concurrent sessions. We >>>> > are moving to >>>> > a >>>> > brick-style environment where we are serving up the entire >>>> > desktop experience >>>> > to the end-user. I have login scripts that control >>>> > application access, mapped drives and printers - all >>>> > associated to related OU and security group >>>> > memberships. In a scenario like this, having a TS Roaming >>>> > profile was almost >>>> > a must - unless we wanted to manage changes to specific user >>>> > accounts across >>>> > 11 server-specific profiles. >>>> > >>>> > I have read old 2000 TS blogs suggesting a way to remove the >>>> > ability for >>>> > users to update file type associations to their profiles and >>>> > to push the >>>> > default associations from the server to each profile, but >>>> > cannot find any >>>> > related 2003 referneces that this is the right course or if >>>> > it even will >>>> > work. >>>> > >>>> > If we do go full brick - there will essestially be no >>>> > client-side garbage >>>> > to >>>> > pass on to the server, right? So, will this cause other >>>> > problems with file-type associations with even more >>>> > applications since the brick cannot >>>> > pass along its table? Any way to remove this ability to >>>> > update file types >>>> > on >>>> > the server for the users AND replicate the default >>>> > associations down threw >>>> > the profiles on each server? Thanks! >>>> > >>>> > "Jeff Pitsch" wrote: >>>> > >>>> >> It sounds like you are using roaming profiles and sharing a >>>> >> profile between >>>> >> a uses desktop and a users terminal server session. I'll >>>> >> be honest with >>>> >> you, this is not what you want to do if this is what is >>>> >> actually happening. >>>> >> You will run into situations exactly what your describing. >>>> >> >>>> >> the best case scenario is to take advantage of the tools >>>> >> that Microsoft >>>> >> has >>>> >> given you. In each user account, you can specify a profile >>>> >> and terminal >>>> >> services profile. You can also specify this in Group >>>> >> Policy. I would highly recommend you do this. This way >>>> >> you will fix the problem and avoid >>>> >> other issues such as profile corruption that you will >>>> >> surely see. Workstation profiles are not meant to be used >>>> >> on terminal services hence >>>> >> why >>>> >> this split is given by Microsoft. Too much garbage ina >>>> >> typical workstation >>>> >> profile that you simply do not want corruputing your >>>> >> terminal services impelmentation. >>>> >> >>>> >> Jeff Pitsch >>>> >> Microsoft MVP - Terminal Services >>>> >> >>>> >> >>>> >> "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote >>>> >> in message >>>> >> news:1512CE15-A032-4636-A8AE-FD867B686726@microsoft.com... >>>> >> >I am having a terrible time trying to resolve an issue >>>> >> >that is braking >>>> >> >many >>>> >> > of the applications I am serving up to users inside their >>>> >> > Remote Desktop >>>> >> > session on a Windows 2003 Terminal Server.... File Type >>>> >> > associations >>>> >> > for >>>> >> > certain extensions show up as "unknown" under certain >>>> >> > user profiles, even >>>> >> > though the server has valid associations already for >>>> >> > apps. Seems like, >>>> >> > if >>>> >> > a >>>> >> > user logs into TS from a machine that has never seem an >>>> >> > infopath form >>>> >> > before >>>> >> > and does not know where to associate an XML file to, the >>>> >> > profile will >>>> >> > not >>>> >> > capture the default association from the server and >>>> >> > leaves it as an unknown. >>>> >> > This is happening for another file type as well, .TIFF. >>>> >> > The only fix I >>>> >> > have >>>> >> > found is to run the assoc command inside the user RD >>>> >> > session, then manually >>>> >> > make the file type association by selecting an XML file >>>> >> > and then selecting >>>> >> > the application from the programs list to open it.... >>>> >> > >>>> >> > THERE HAS TO BE A FIX FOR THIS OR AN EASIER METHOD FOR >>>> >> > PUSHING FILE TYPE >>>> >> > ASSOCIATIONS ACCROSS 500 USER PROFILES AND 12 TERMINAL >>>> >> > SERVERS!!!!!! >>>> >> > >>>> >> > Any help would be a blessing at this point.. Thanks!
Guest Vera Noest [MVP] Posted July 3, 2008 Posted July 3, 2008 Re: File Type Associations W2K3 Hi Jeff, good to see to back here! I'm not sure, maybe you mean by using compatibility flags? Never tried if that works for file associations. Program compatibility flags http://technet2.microsoft.com/windowsserver/en/library/df78c476- 00d5-41f0-a21d-e1e12e3d1f8b1033.mspx?mfr=true _________________________________________________________ Vera Noest MCSE, CCEA, Microsoft MVP - Terminal Server TS troubleshooting: http://ts.veranoest.net ___ please respond in newsgroup, NOT by private email ___ "Jeff Pitsch" <jeff@jeffpitschconsulting.com> wrote on 03 jul 2008 in microsoft.public.windows.terminal_services: > Hey Vera, I may have gone completely crazy but I would have > sworn there was a way to tell windows to ignore the HKCU keys > altogether. > > Jeff Pitsch > Microsoft MVP - Terminal Services > > > > "Vera Noest [MVP]" <vera.noest@remove-this.hem.utfors.se> wrote > in message > news:Xns9AD0DF23617F5veranoesthemutforsse@207.46.248.16... >> The problem is documented here: >> >> 257592 - Changes in File Types and File Association Features in >> Windows 2000 and Windows Server 2003 >> http://support.microsoft.com/?kbid=257592 >> >> So you'll have to let the users import a .reg file to create >> the file associations. >> _________________________________________________________ >> Vera Noest >> MCSE, CCEA, Microsoft MVP - Terminal Server >> TS troubleshooting: http://ts.veranoest.net >> ___ please respond in newsgroup, NOT by private email ___ >> >> "Jeff Pitsch" <jeff@jeffpitschconsulting.com> wrote on 03 jul >> 2008 in microsoft.public.windows.terminal_services: >> >>> Here's one way: >>> http://technet2.microsoft.com/windowsserver/en/library/2955fe3f >>> -7 47e-46a6-8825-eb9eb7baacae1033.mspx?mfr=true >>> >>> And I'm almost positive there is another way of doing it >>> through GPO or something but mind is drawing a blank. I'm >>> still searching though and will let you know if I find >>> anything. >>> >>> Jeff Pitsch >>> Microsoft MVP - Terminal Services >>> >>> >>> "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote in >>> message >>> news:DC0A24F9-4EBC-4078-8058-4B8AD2D75B62@microsoft.com... >>>>I am using TS Roaming profiles. We removed all login Roaming >>>>profiles from >>>> our AD schema years ago due to a ton of problems surrounding >>>> maintaining/maintenancing them..... >>>> >>>> So, if I understand right - If I updated the file type >>>> associations in the HKCU programmatically thru the Terminal >>>> Server login scripts I already have >>>> in place, this may be a quick fix for problematic file types >>>> and correct any >>>> legacy profiles that were incorrect? I have the TS sessions >>>> locked down very >>>> hard, would this approach require users to have registry >>>> access to make this >>>> update? Do you see any problems that may occur from 20 plus >>>> users concurrently making registry hacks at login? Do you >>>> know of any way to remove the user's ability to update file >>>> type associations for their profiles >>>> going forward if this works? >>>> >>>> Thanks again! >>>> >>>> "Jeff Pitsch" wrote: >>>> >>>>> Are you using TS roaming profiles right now or the default >>>>> workstation roaming profiles? >>>>> >>>>> there is also a HKCU key for every users and a filetype >>>>> assocation key for >>>>> every user (classes root entries). You will always have >>>>> user registry entries to deal with but with a clean server >>>>> or a new profile being generated for users they should not >>>>> have the problem of overriding HKCU keys. If the profile is >>>>> being reused from workstations then yes this problem is >>>>> there. If you delete and recreate the users profile does >>>>> the situation still exist? >>>>> >>>>> >>>>> Jeff Pitsch >>>>> Microsoft MVP - Terminal Services >>>>> >>>>> >>>>> "Garrett1226" <Garrett1226@discussions.microsoft.com> wrote >>>>> in message >>>>> news:373B76C1-19C4-487A-9CCA-8BB34CA36F13@microsoft.com... >>>>> > Jeff, thanks for the quick response... We have a Terminal >>>>> > Services Farm >>>>> > of >>>>> > 11 servers to load balance our 200 concurrent sessions. >>>>> > We are moving to >>>>> > a >>>>> > brick-style environment where we are serving up the entire >>>>> > desktop experience >>>>> > to the end-user. I have login scripts that control >>>>> > application access, mapped drives and printers - all >>>>> > associated to related OU and security group >>>>> > memberships. In a scenario like this, having a TS Roaming >>>>> > profile was almost >>>>> > a must - unless we wanted to manage changes to specific >>>>> > user accounts across >>>>> > 11 server-specific profiles. >>>>> > >>>>> > I have read old 2000 TS blogs suggesting a way to remove >>>>> > the ability for >>>>> > users to update file type associations to their profiles >>>>> > and to push the >>>>> > default associations from the server to each profile, but >>>>> > cannot find any >>>>> > related 2003 referneces that this is the right course or >>>>> > if it even will >>>>> > work. >>>>> > >>>>> > If we do go full brick - there will essestially be no >>>>> > client-side garbage >>>>> > to >>>>> > pass on to the server, right? So, will this cause other >>>>> > problems with file-type associations with even more >>>>> > applications since the brick cannot >>>>> > pass along its table? Any way to remove this ability to >>>>> > update file types >>>>> > on >>>>> > the server for the users AND replicate the default >>>>> > associations down threw >>>>> > the profiles on each server? Thanks! >>>>> > >>>>> > "Jeff Pitsch" wrote: >>>>> > >>>>> >> It sounds like you are using roaming profiles and sharing >>>>> >> a profile between >>>>> >> a uses desktop and a users terminal server session. I'll >>>>> >> be honest with >>>>> >> you, this is not what you want to do if this is what is >>>>> >> actually happening. >>>>> >> You will run into situations exactly what your >>>>> >> describing. >>>>> >> >>>>> >> the best case scenario is to take advantage of the tools >>>>> >> that Microsoft >>>>> >> has >>>>> >> given you. In each user account, you can specify a >>>>> >> profile and terminal >>>>> >> services profile. You can also specify this in Group >>>>> >> Policy. I would highly recommend you do this. This way >>>>> >> you will fix the problem and avoid >>>>> >> other issues such as profile corruption that you will >>>>> >> surely see. Workstation profiles are not meant to be used >>>>> >> on terminal services hence >>>>> >> why >>>>> >> this split is given by Microsoft. Too much garbage ina >>>>> >> typical workstation >>>>> >> profile that you simply do not want corruputing your >>>>> >> terminal services impelmentation. >>>>> >> >>>>> >> Jeff Pitsch >>>>> >> Microsoft MVP - Terminal Services >>>>> >> >>>>> >> >>>>> >> "Garrett1226" <Garrett1226@discussions.microsoft.com> >>>>> >> wrote in message >>>>> >> news:1512CE15-A032-4636-A8AE-FD867B686726@microsoft.com... >>>>> >> >I am having a terrible time trying to resolve an issue >>>>> >> >that is braking >>>>> >> >many >>>>> >> > of the applications I am serving up to users inside >>>>> >> > their Remote Desktop >>>>> >> > session on a Windows 2003 Terminal Server.... File >>>>> >> > Type associations >>>>> >> > for >>>>> >> > certain extensions show up as "unknown" under certain >>>>> >> > user profiles, even >>>>> >> > though the server has valid associations already for >>>>> >> > apps. Seems like, >>>>> >> > if >>>>> >> > a >>>>> >> > user logs into TS from a machine that has never seem an >>>>> >> > infopath form >>>>> >> > before >>>>> >> > and does not know where to associate an XML file to, >>>>> >> > the profile will >>>>> >> > not >>>>> >> > capture the default association from the server and >>>>> >> > leaves it as an unknown. >>>>> >> > This is happening for another file type as well, .TIFF. >>>>> >> > The only fix I >>>>> >> > have >>>>> >> > found is to run the assoc command inside the user RD >>>>> >> > session, then manually >>>>> >> > make the file type association by selecting an XML file >>>>> >> > and then selecting >>>>> >> > the application from the programs list to open it.... >>>>> >> > >>>>> >> > THERE HAS TO BE A FIX FOR THIS OR AN EASIER METHOD FOR >>>>> >> > PUSHING FILE TYPE >>>>> >> > ASSOCIATIONS ACCROSS 500 USER PROFILES AND 12 TERMINAL >>>>> >> > SERVERS!!!!!! >>>>> >> > >>>>> >> > Any help would be a blessing at this point.. Thanks!
Recommended Posts