Path not found (with details), English ins...
psouza4
13 Feb 2009
Cristiano, on Jan 20 2009, 01:27 AM, said:
> I think the thread's abandoned
no, it isn't. we just are having a lot of issues and i can't promisse anything regarding time to fix something right now
no, it isn't. we just are having a lot of issues and i can't promisse anything regarding time to fix something right now
How about now?
I'm still twiddling my thumbs and checking the forums every week waiting for a reply or some kind of help; it's been two and a half months. I still can't use AutoPatcher (at all) on this system. And I'm not alone with this issue.
Is anyone able to assist?
_def_x_
13 Feb 2009
Well, Erik is gone - who knows for how long.
I noticed you were using AutoPatcher and APUP interchangeably...
You said you had 3 other machines that APUP worked fine on, can you at least update this
problematic server box using AutoPatcher (if you haven't all ready done so?) I can't tell if your
problem is with both pieces of software, if not, create a module from one of the other machines
and update the box using AutoPatcher.
The development team is stretched really thin at the moment, they are trying to get the scripts updated
in their spare time and who knows if they will have time to try and dissect this more deeply.
BTW, I asked a friend if he would mind running APUP on his Server box and he had no issues - APUP worked
fine he said. There clearly is a problem but seems rare and difficult to pin down.
Mike
I noticed you were using AutoPatcher and APUP interchangeably...
Quote
On launch, apup.exe produces the following errors
Quote
Looks like AutoPatcher is having a problem with my environment settings
Quote
I still can't use AutoPatcher (at all) on this system
problematic server box using AutoPatcher (if you haven't all ready done so?) I can't tell if your
problem is with both pieces of software, if not, create a module from one of the other machines
and update the box using AutoPatcher.
The development team is stretched really thin at the moment, they are trying to get the scripts updated
in their spare time and who knows if they will have time to try and dissect this more deeply.
BTW, I asked a friend if he would mind running APUP on his Server box and he had no issues - APUP worked
fine he said. There clearly is a problem but seems rare and difficult to pin down.
Mike
psouza4
19 Mar 2009
I spent more time researching this today and have a fix:
The way Windows Installer and .Net applications see the WINDOWS folder under Terminal Services forces them to see it as relative to the user's home path, even if logging into that user and using SET (or various script host methods) from a command prompt does not. Once you know where to look, this is well documented all over the internet.
The solution I found was to drop to DOS as that user and type:
And then perform the installations as required. This was affecting latest versions of AutoPatcher, AutoPatcher Updater, Everest Ultimate Edition, and NetLimiter. Probably a slew of other software too that I have no reason to try.
After you're done, type:
To resume standard operations for the user. In this case, I was remoted directly into the machine via VNC, who was logged in as the local administrator account. And it still had this terminal server issue.
You can also disable this substitution on a per-application basis by modifying the compatibility bits registry settings as described in this Microsoft KB article:
http://support.microsoft.com/kb/186499
References:
http://www.techotopia.com/index.php/Instal...rminal_Services
http://www.codeguru....threadid=362400
(Despite the above article for Windows Server 2008, it also applies to the solution for 2003.)
Edited by psouza4, 19 March 2009 - 07:57 PM.
The way Windows Installer and .Net applications see the WINDOWS folder under Terminal Services forces them to see it as relative to the user's home path, even if logging into that user and using SET (or various script host methods) from a command prompt does not. Once you know where to look, this is well documented all over the internet.
The solution I found was to drop to DOS as that user and type:
change user /install
And then perform the installations as required. This was affecting latest versions of AutoPatcher, AutoPatcher Updater, Everest Ultimate Edition, and NetLimiter. Probably a slew of other software too that I have no reason to try.
After you're done, type:
change user /execute
To resume standard operations for the user. In this case, I was remoted directly into the machine via VNC, who was logged in as the local administrator account. And it still had this terminal server issue.
You can also disable this substitution on a per-application basis by modifying the compatibility bits registry settings as described in this Microsoft KB article:
http://support.microsoft.com/kb/186499
References:
http://www.techotopia.com/index.php/Instal...rminal_Services
http://www.codeguru....threadid=362400
(Despite the above article for Windows Server 2008, it also applies to the solution for 2003.)
Edited by psouza4, 19 March 2009 - 07:57 PM.
_def_x_
19 Mar 2009
James
19 Mar 2009
psouza4, on Mar 19 2009, 07:39 PM, said:
I spent more time researching this today and have a fix
psouza4 said:
Once you know where to look, this is well documented all over the internet.
--
