From: jeffreyl on 3 Jan 2007 15:50 I know there are many TS experts in this group. Can I get some advices, please? I have installed a VB application on Terminal Server box and part of the application is failed with either admin or normal user. Following are details.. Application installation and issues: 1. I have a box with Windows Server 2003 standard + SP1 installed and the server was configured to TS mode. Permission Compatibility has set to "Relaxed Security" 2. Log on to the TS with user having admin right. 3. Change the TS to install mode explicitly with "change user /install" 4. Run the Installation package of the VB application successfully. 5. Start and run the application with no error (including all the menu buttons). Close the application 6. Change TS to execute mode by "change user /execute" 7. With the same logon user (admin right), re-start the application. The application has launched with no error, all meun button works except one, which launches a new window, failed with error: "Fail to create object." (a registered .ocx). 8. Log on the TS with normal user, same error with #7 What I found so far: Registry: 1. The installation writes all registry entries to HKLM, apart from few empty keys in HKCU 2. Corresponding shallow keys (..../terminal server/install/software) are created for those empty keys as well. 3. No entries in any of the sub keys under .../terminal server/Compatibility/ 4. There is no .INI file created during the installation in the System directory Regmon and Filemon: 1. There is no File access during launching and running the application in either mode 2. In "Install mode" the registered object key was queried in both HKLM and HKCR, and somehow loaded successfully from HKCR 3. In "Execute mode" the registered object key was only queried in HKLM, but not HKCR 4. There is no "ACCESS DENIED" entries running in either mode I'd like to figure out what registry entries are changed when executing "Change User /install" command, which changes the behaviour of reading the registry entries of the runtime application. Dose anyone ecounter similar issues before? Any ideas of the possible solutions? Many thanks, Jeff
From: jeffreyl on 3 Jan 2007 18:27 To be more specific, The application fails to load any form contains a specific third party ..ocx control in EXECUTE mode (it runs ok in INSTALL mode). I have registered the control in "Install mode" under Admin account using regsvr32. Thanks guys, Jeff jeffreyl(a)adhb.govt.nz wrote: > I know there are many TS experts in this group. Can I get some > advices, please? > > I have installed a VB application on Terminal Server box and part of > the application is failed with either admin or normal user. Following > are details.. > > Application installation and issues: > 1. I have a box with Windows Server 2003 standard + SP1 installed and > the server was configured to TS mode. Permission Compatibility has set > to "Relaxed Security" > 2. Log on to the TS with user having admin right. > 3. Change the TS to install mode explicitly with "change user > /install" > 4. Run the Installation package of the VB application successfully. > 5. Start and run the application with no error (including all the menu > buttons). Close the application > 6. Change TS to execute mode by "change user /execute" > 7. With the same logon user (admin right), re-start the application. > The application has launched with no error, all meun button works > except one, which launches a new window, failed with error: "Fail to > create object." (a registered .ocx). > 8. Log on the TS with normal user, same error with #7 > > What I found so far: > Registry: > 1. The installation writes all registry entries to HKLM, apart from > few empty keys in HKCU > 2. Corresponding shallow keys (..../terminal server/install/software) > are created for those empty keys as well. > 3. No entries in any of the sub keys under .../terminal > server/Compatibility/ > 4. There is no .INI file created during the installation in the System > directory > > Regmon and Filemon: > 1. There is no File access during launching and running the > application in either mode > 2. In "Install mode" the registered object key was queried in both > HKLM and HKCR, and somehow loaded successfully from HKCR > 3. In "Execute mode" the registered object key was only queried in > HKLM, but not HKCR > 4. There is no "ACCESS DENIED" entries running in either mode > > I'd like to figure out what registry entries are changed when executing > "Change User /install" command, which changes the behaviour of reading > the registry entries of the runtime application. > > Dose anyone ecounter similar issues before? Any ideas of the possible > solutions? > > Many thanks, > Jeff
From: Wimpie van Lingen on 4 Jan 2007 03:10 Hi I've got a similar problem, although my error is caused by a dll that doesn't register correctly instead of an ocx. I wonder if it is possible that this problem is caused by one of Microsoft's newer updates from Windows Update. We've used an application on Terminal Server for years now and after the last time we did an update, we are stuck with this problem (we had to re-register the dll's). This is the first time ever we've had a problem like this and now suddenly someone is experiencing a similar problem. My post was news:u4cuRRmLHHA.1280(a)TK2MSFTNGP04.phx.gbl titled "ActiveX Component can't create object" but no-one could really help me so far. <jeffreyl(a)adhb.govt.nz> wrote in message news:1167866868.207313.72390(a)42g2000cwt.googlegroups.com... > To be more specific, > > The application fails to load any form contains a specific third party > .ocx control in EXECUTE mode (it runs ok in INSTALL mode). > > I have registered the control in "Install mode" under Admin account > using regsvr32. > > Thanks guys, > > Jeff > > jeffreyl(a)adhb.govt.nz wrote: >> I know there are many TS experts in this group. Can I get some >> advices, please? >> >> I have installed a VB application on Terminal Server box and part of >> the application is failed with either admin or normal user. Following >> are details.. >> >> Application installation and issues: >> 1. I have a box with Windows Server 2003 standard + SP1 installed and >> the server was configured to TS mode. Permission Compatibility has set >> to "Relaxed Security" >> 2. Log on to the TS with user having admin right. >> 3. Change the TS to install mode explicitly with "change user >> /install" >> 4. Run the Installation package of the VB application successfully. >> 5. Start and run the application with no error (including all the menu >> buttons). Close the application >> 6. Change TS to execute mode by "change user /execute" >> 7. With the same logon user (admin right), re-start the application. >> The application has launched with no error, all meun button works >> except one, which launches a new window, failed with error: "Fail to >> create object." (a registered .ocx). >> 8. Log on the TS with normal user, same error with #7 >> >> What I found so far: >> Registry: >> 1. The installation writes all registry entries to HKLM, apart from >> few empty keys in HKCU >> 2. Corresponding shallow keys (..../terminal server/install/software) >> are created for those empty keys as well. >> 3. No entries in any of the sub keys under .../terminal >> server/Compatibility/ >> 4. There is no .INI file created during the installation in the System >> directory >> >> Regmon and Filemon: >> 1. There is no File access during launching and running the >> application in either mode >> 2. In "Install mode" the registered object key was queried in both >> HKLM and HKCR, and somehow loaded successfully from HKCR >> 3. In "Execute mode" the registered object key was only queried in >> HKLM, but not HKCR >> 4. There is no "ACCESS DENIED" entries running in either mode >> >> I'd like to figure out what registry entries are changed when executing >> "Change User /install" command, which changes the behaviour of reading >> the registry entries of the runtime application. >> >> Dose anyone ecounter similar issues before? Any ideas of the possible >> solutions? >> >> Many thanks, >> Jeff >
From: Dragos CAMARA on 4 Jan 2007 08:53 A program might create HKEY_CURRENT_USER registry settings the first time a user runs the program, rather than during installation. If you do not run the program while install mode is still active, the HKEY_CURRENT_USER settings are not copied to HKEY_LOCAL_MACHINE. The first time each user runs the program, HKEY_CURRENT_USER will be loaded with the default settings. Depending on the program, this might or might not be appropriate. If the default settings are not sufficient, they need to be corrected for each user individually. To avoid this problem, run the program once before clicking Finish in Add\Remove Programs (or before running change user /execute). This will cause the program to create the necessary registry settings. If you have already left install mode and have not run the program, re-enter install mode with change user /install and run the program. If you have already run the program while in execute mode, create another administrator account, log on with this new account, run change user /install, run the program, and then run change user /execute to leave install mode. Did you try to register the ocx in execute mode? -- Dragos CAMARA MCSA Windows 2003 server "jeffreyl(a)adhb.govt.nz" wrote: > To be more specific, > > The application fails to load any form contains a specific third party > ..ocx control in EXECUTE mode (it runs ok in INSTALL mode). > > I have registered the control in "Install mode" under Admin account > using regsvr32. > > Thanks guys, > > Jeff > > jeffreyl(a)adhb.govt.nz wrote: > > I know there are many TS experts in this group. Can I get some > > advices, please? > > > > I have installed a VB application on Terminal Server box and part of > > the application is failed with either admin or normal user. Following > > are details.. > > > > Application installation and issues: > > 1. I have a box with Windows Server 2003 standard + SP1 installed and > > the server was configured to TS mode. Permission Compatibility has set > > to "Relaxed Security" > > 2. Log on to the TS with user having admin right. > > 3. Change the TS to install mode explicitly with "change user > > /install" > > 4. Run the Installation package of the VB application successfully. > > 5. Start and run the application with no error (including all the menu > > buttons). Close the application > > 6. Change TS to execute mode by "change user /execute" > > 7. With the same logon user (admin right), re-start the application. > > The application has launched with no error, all meun button works > > except one, which launches a new window, failed with error: "Fail to > > create object." (a registered .ocx). > > 8. Log on the TS with normal user, same error with #7 > > > > What I found so far: > > Registry: > > 1. The installation writes all registry entries to HKLM, apart from > > few empty keys in HKCU > > 2. Corresponding shallow keys (..../terminal server/install/software) > > are created for those empty keys as well. > > 3. No entries in any of the sub keys under .../terminal > > server/Compatibility/ > > 4. There is no .INI file created during the installation in the System > > directory > > > > Regmon and Filemon: > > 1. There is no File access during launching and running the > > application in either mode > > 2. In "Install mode" the registered object key was queried in both > > HKLM and HKCR, and somehow loaded successfully from HKCR > > 3. In "Execute mode" the registered object key was only queried in > > HKLM, but not HKCR > > 4. There is no "ACCESS DENIED" entries running in either mode > > > > I'd like to figure out what registry entries are changed when executing > > "Change User /install" command, which changes the behaviour of reading > > the registry entries of the runtime application. > > > > Dose anyone ecounter similar issues before? Any ideas of the possible > > solutions? > > > > Many thanks, > > Jeff > >
From: jeffreyl on 4 Jan 2007 19:30 Thanks for your reponse, I had tried to register the ocx in both modes, it didn't work. I guess that I found the problem. Just noticed that the installation did copy an .INI file (with a date of 2003) into the System directory. When the application runs in INSTALL mode, it looks for the INI file in System directory. Everything is OK. Switch to Execute mode, the application looks for "SystemRoot\LoginUser$\Windows" dirctory for INI file. BUT, I am working in one of the "Virtural Machine"s on the Terminal server box (I hope the terms I used are right), which returns Terminal server's root directory instead of the root directory of the "Virtual Machine" I am in, so the application failed to load the INI file (it's actually not there at all, because it couldn't copy the INI file from System directory in the first place when I switch to Execute mode). E.g. the Server box has name SerName and virtual machine I am in has name VirName the application is look for "SerName\LoginUser$\Windows" directory for INI file I hope I had explained clear enough what the problem is. This is not an elegent solution. Copy the INI file to the Terminal Server\LoginUser\Windows directory Reasons of having a Terminal Server RootDirectory returned: my admin account for that "Virtual Machine" was created by the Terminal Server's System Administrator, so I am in the admin group of the server. When I have the admin privilage of the Virtual Machine, I created other normal user's account and when he/she run the application, the root directory is local "C:\Document and Setting\LoginUser\Windows". When I logon as normal user, the server doesn't copy the INI file to user's local directory, I guess that because the INI belongs to the ocx rather than an .exe file. Hopefully that's not too confusing. Thanks, Jeff Dragos CAMARA wrote: > A program might create HKEY_CURRENT_USER registry settings the first time a > user runs the program, rather than during installation. If you do not run the > program while install mode is still active, the HKEY_CURRENT_USER settings > are not copied to HKEY_LOCAL_MACHINE. The first time each user runs the > program, HKEY_CURRENT_USER will be loaded with the default settings. > Depending on the program, this might or might not be appropriate. If the > default settings are not sufficient, they need to be corrected for each user > individually. > > To avoid this problem, run the program once before clicking Finish in > Add\Remove Programs (or before running change user /execute). This will cause > the program to create the necessary registry settings. > > If you have already left install mode and have not run the program, re-enter > install mode with change user /install and run the program. If you have > already run the program while in execute mode, create another administrator > account, log on with this new account, run change user /install, run the > program, and then run change user /execute to leave install mode. > > Did you try to register the ocx in execute mode? > -- > Dragos CAMARA > MCSA Windows 2003 server > > > "jeffreyl(a)adhb.govt.nz" wrote: > > > To be more specific, > > > > The application fails to load any form contains a specific third party > > ..ocx control in EXECUTE mode (it runs ok in INSTALL mode). > > > > I have registered the control in "Install mode" under Admin account > > using regsvr32. > > > > Thanks guys, > > > > Jeff > > > > jeffreyl(a)adhb.govt.nz wrote: > > > I know there are many TS experts in this group. Can I get some > > > advices, please? > > > > > > I have installed a VB application on Terminal Server box and part of > > > the application is failed with either admin or normal user. Following > > > are details.. > > > > > > Application installation and issues: > > > 1. I have a box with Windows Server 2003 standard + SP1 installed and > > > the server was configured to TS mode. Permission Compatibility has set > > > to "Relaxed Security" > > > 2. Log on to the TS with user having admin right. > > > 3. Change the TS to install mode explicitly with "change user > > > /install" > > > 4. Run the Installation package of the VB application successfully. > > > 5. Start and run the application with no error (including all the menu > > > buttons). Close the application > > > 6. Change TS to execute mode by "change user /execute" > > > 7. With the same logon user (admin right), re-start the application. > > > The application has launched with no error, all meun button works > > > except one, which launches a new window, failed with error: "Fail to > > > create object." (a registered .ocx). > > > 8. Log on the TS with normal user, same error with #7 > > > > > > What I found so far: > > > Registry: > > > 1. The installation writes all registry entries to HKLM, apart from > > > few empty keys in HKCU > > > 2. Corresponding shallow keys (..../terminal server/install/software) > > > are created for those empty keys as well. > > > 3. No entries in any of the sub keys under .../terminal > > > server/Compatibility/ > > > 4. There is no .INI file created during the installation in the System > > > directory > > > > > > Regmon and Filemon: > > > 1. There is no File access during launching and running the > > > application in either mode > > > 2. In "Install mode" the registered object key was queried in both > > > HKLM and HKCR, and somehow loaded successfully from HKCR > > > 3. In "Execute mode" the registered object key was only queried in > > > HKLM, but not HKCR > > > 4. There is no "ACCESS DENIED" entries running in either mode > > > > > > I'd like to figure out what registry entries are changed when executing > > > "Change User /install" command, which changes the behaviour of reading > > > the registry entries of the runtime application. > > > > > > Dose anyone ecounter similar issues before? Any ideas of the possible > > > solutions? > > > > > > Many thanks, > > > Jeff > > > >
|
Pages: 1 Prev: Local Drives not accessible Next: Handle leak in Remote Desktop Web Connection? |