24 replies to this topic

[psouza4]

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

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_]

Well, Erik is gone - who knows for how long.

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

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

[psouza4]

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:

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_]

unfortunately, the Server 2003 release has been suspended for now.

Read Here.

Mike

[James]

psouza4, on Mar 19 2009, 07:39 PM, said:

I spent more time researching this today and have a fix

That's very good news.

psouza4 said:

Once you know where to look, this is well documented all over the internet.

It certainly is, as in 113,000 hits in Google (after filtering out 26,390,000 irrelevant hits!!)

--