ADT2005 Service Patch 1 errors out with 1602 code

Okay, I know why this is happening. What I need is a solution.
Here's the deal:
1. 45 user Network license of ADT2005, software installed through NIW to
each workstation.
2. Content, Menus, plot configs, etc., stored on a Read-Only network drive

The 1602 error occurs for 2 reasons:
1. Someone else is using ADT2005 and/or
2. The user I'm trying to update doesn't have write privileges to the
network drive.

What this means is:
1. I have to do patching before or after work hours when NO ONE is using the
software.
2. I have to get the IT guys to grant write privileges to users that I don't
want to have these privileges.

Honestly, I'd like to wring the BOZO's neck at Autodesk who came up with
this!

Short of that, does anyone have a way for me to apply this patch during
normal working hours under normal working conditions. I've already tried
creating a profile that points only to local folders on the C: drive, but
that doesn't work either.

Thanks.

--
Regards,
---------------
Reid M. Addis
Registered Architect
Architectural Applications Specialist
Granary Associates
411 North 20th Street
Philadelphia, PA 19130
Ph. 215-665-7056
email:

 

Hi Reid,

Have you taken a look at the recent %temp%\*.log files? There should be an
install log that gives more information about which files failed to be
written. Also, it seems that 1602 is a more generic "User canceled" type
error... The log file should have another MSI error code just before that
one that may give you a better clue.

Have you tried temporarily giving that user write access to your content
folder, or applying the service pack logged in as a user that already has
access? It doesnt matter which user applies the service pack.

Also, it's possible that after the specific network files have been updated
once, it may not need write access a second time. I've seen it happen
before... You might get lucky.

I assume you have seen this?
http://usa.autodesk.com/adsk/servlet/ps/item?siteID=123112&id=4900255&linkID=2476059

Chris

 

Thanks Chris.
I'll check out the link.
This is definitely an Autodesk screw up that they need to fix. Users MUST
have write privileges AND no one else may have networked shared files open
in order to patch the product. This is, of course, impossible to achieve
during normal business hours!

--
Regards,
---------------
Reid M. Addis
Registered Architect
Architectural Applications Specialist
Granary Associates
411 North 20th Street
Philadelphia, PA 19130
Ph. 215-665-7056
email:

 

After looking at the link:
Yeah! Well, DUH!
Of course this is exactly the problem. Doesn't take genius to figure it out.
I need a solution!

1. There is NO REASON my users need write access to these network files. I
DON'T want them to be able to change them.
2. There is absolutely NO REASON why either during the initial install or
patches that these files would need to be accessed. There is no code beyond
menus, pgp files, etc.

--
Regards,
---------------
Reid M. Addis
Registered Architect
Architectural Applications Specialist
Granary Associates
411 North 20th Street
Philadelphia, PA 19130
Ph. 215-665-7056
email:

 

Could this be your problem/solution? (From the sp1 readme)

"None of your customized files should be affected by this patch. However, if
you are using a file that has a date earlier than the date of the file
originally installed by ADT 2005, it will be replaced. For example, if you
have simply copied acad.pgp from ADT 2004, it will have a modified date that
is before the release of ADT 2005 and will be replaced. To avoid this issue,
simply re-save the customized file, which will give it a later date, thus
preventing its replacement.
Note that any files which have been removed (or moved) after the original
installation will be restored by this patch."

So the trick may be to make the patch think that it doesnt need to update
the in-use or read-only files. To find out which files, take a look at the
MSI log file. You might need to enable all the options in the windows
installer logging policy to give you a more detailed log file. Post it
here if you need further help.

Chris

 

Hey Chris,
Where would the log file be stored? And, what would it be called?

Also, what files ARE patched? If I have a successful patch on one machine,
why can't I just copy those to ALL the machines?
Thanks!

--
Regards,
---------------
Reid M. Addis
Registered Architect
Architectural Applications Specialist
Granary Associates
411 North 20th Street
Philadelphia, PA 19130
Ph. 215-665-7056
email:

 

The readme for the service pack lists all the files updated. However, it
doesnt have their full paths listed, and I *suspect* there are more ADT
specific content related files that are not listed. I could be wrong.

Type %TEMP% in an explorer address to get to the real temp folder for the
current user. It will be the largest *.log file that was generated near
the time of the error message. Might be ADT.LOG or MSIxxx.log.

Chris

 

They dont look quite right... the correct file will reference the 1602
error.

ADT 2005.log I think. check %TEMP% folder and sort by date.

 

That's what I did.
These were the latest files created. Did you look all the way down?
Seems to cover ADT2005 towards the bottom half of the file.
I'll check again.

Thanks.

--
Regards,
---------------
Reid M. Addis
Registered Architect
Architectural Applications Specialist
Granary Associates
411 North 20th Street
Philadelphia, PA 19130
Ph. 215-665-7056
email:

 

Enable full logging, reboot. run the setup and look in the temp folder
again....
http://www.winguides.com/registry/display.php/1127/

I'm sure it will be an ADT 2005.log, and the top of the file should look
like this:

=== Verbose logging started

Find the 1602 error, then slowly scan UP the log file for other errors.
You may be able to track down the specific file that it fails on.
My guess would be an ADT DWT template file.

Might want to zip it, it can get pretty large.

 

Cool!
Now, here's another question.
Would there be something I could change in a "Profile" that would point to
this file somewhere else that is read/write capable?
I used an NIW for software installation, and tried creating a profile that
pointed to only local folders on the c: drive, but that didn't work.

--
Regards,
---------------
Reid M. Addis
Registered Architect
Architectural Applications Specialist
Granary Associates
411 North 20th Street
Philadelphia, PA 19130
Ph. 215-665-7056
email:

 

A few quick thoughts...

- Open acad and reload the ADT menu from the local drive before running the
service pack update...
Options > Files > Menu, help > Menu file

- Or maybe it uses this reg key? Try changing the path to ADT.DLL, and
reapply sp.
HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\R16.1\ACAD-304:409\aecCabinet\CabFiles\adtMenus.cab\Files

- There could be another "Installer" registry key that keeps track of where
ADT.DLL was -originally- installed to, so thats why changes to the current
users profile wouldnt help... If this was the case, it would be under
HKEY_LOCAL_MACHINE... I may get a chance to dig a bit more later.

Chris

 

Chris:
1.Changing the menu file AND adt.dll location doesn't help.
2. You must have a non-network install like me. A network install does NOT
have a
HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\R16.1\ACAD-304:409\aecCabinet\Ca
bFiles\adtMenus.cab\Files key. It ends at the adtMenus.cab level.
3. Even with that said, a registry search on my station for ADT.DLL only
turns up a setting for ADT2004. Nothing for ADT2005.

Other thoughts?

--
Regards,
---------------
Reid M. Addis
Registered Architect
Architectural Applications Specialist
Granary Associates
411 North 20th Street
Philadelphia, PA 19130
Ph. 215-665-7056
email:

 

Perhaps this has to be fixed in the original MSI or MSP patch file. You
would have to use a program like Microsoft Orca or Installshield to edit the
file. It's not for the faint of heart!

From an older thread of yours (search on 1602) I see that it will be fixed
for the next service pack.

In the future, consider leaving the ADT.* files on each local drive in their
original location. Toolbar customization should *generally* be done in
Custom.mn?, which can be left on the network. If you have made
modifications to ADT.MN?, then maybe try leaving only ADT.DLL on the local
drive the next time around. I'm not sure this will work... The DLL may
have to be in the SAME folder as the menu files, not elsewhere in the search
path.

I assume you don't have administrative rights to be able to kill the open
file handles of ADT.DLL from the server? I still think that trick I
suggested before may work.

Otherwise, I guess it's back to staying up past your bed time in order to
get the service packs installed? That's why they pay you the big bucks,
right?

Chris