Topic: Networked Palette Management: 2008

[KewlToyZ]

I'm running into some issues when trying to manage palettes over the network.
I use a mapped drive location for their
support files,
discipline specific blocks,
templates,
plotters,
drivers,
palettes.

A single central network profile pointed to by their desktop shortcut.
Default Workspaces in an Enterprise cui file with their own mapped custom cui to save their workspaces to.
The palettes directory has been set to read only for all other users.
Any changes I make, I copy over the files I made on a dev server rather than write directly to them.
I refresh and overwrite the profile everytime I alter the palettes.
But the only way I can get their workstations to recognize palette updates at times is to delete the C:\Documents and Settings\UserName\Application Data\Autodesk\ACD-MEP 2008\enu\Support\Profiles\TheCustomProfile   directory and start it up again.

Anyone find a workaround?
I have users completely lose the palette groups as well with their mapping set properly too?

[pmvliet]

Is there anything in that local directory except the *.AWS file?

Is there a reason you are overwriting the profile after each update?

Are your company profiles located on the server in a central location?
Do you have Autocad to pull that profile upon startup?

let me know that answers and I'll add more.

Pieter

[KewlToyZ]

I'm using the Active Directory fome directory for each user to retain their settings as a workspace in a personal or custom cui file.
I am not able to gain control of that Profile.aws file,
I tried before and it would appear the file is compiled on startup rather than read.
The file won't seem to work from the home directory,
it appears to always go to the
%userprofile%\Application Data\Autodesk\ACD-MEP 2008\enu\Support\profiles\MEP
directory for the Profile.aws file.

This configuration allows for some settings to be user friendly still like their command line and crosshair colors etc...
But the palettes are making me scratch my head still.
Especially since they can no longer be exported.

I use a single central network directory containing the MEP.arg file and customizations with the enterprise.cui file.

[pmvliet]

If your MEP.arg file is on the network, then are you using a profile switch with your Autocad startup icon?  (/p option)
When you update this profile on the network, Autocad will not update the profile on the local systems
Being that it exists already. In order to have the profile update on the local stations, the profile cannot exist.
You can accomplish this several ways.

The AWS file stores information in regards to tool palette's as much as I can tell.
On my system though, I do not get that to happen unless I export a profile.
Your MEP.arg, has the same data in it at the very end. It's sort of duplicated.
Granted, I have not verified this for 2008, but for 2007 that is true.

If you don't overwrite the profile, do the users noT see any changes you make to tool
palette's?

Pieter

[KewlToyZ]

"MEP.arg file is on the network, then are you using a profile switch with your Autocad startup icon. MEP.arg, has the same data in it at the very end"

That is the fact and reason I used the networked profile to handle the palette updates.
Apparently if I setup an overwrite of that aws file with their windows logon, I get mixed results, some crashes even though it is a direct copy of my own. I've tried editing it with TextPad but it quit working and created a new file.

I guess I will need to perform an aws file deletion with each update since it does not seem to be allowing a manual update.
Why the redundancy I have no idea...

[pmvliet]

Apparently if I setup an overwrite of that aws file with their windows logon, I get mixed results, some crashes even though it is a direct copy of my own. I've tried editing it with TextPad but it quit working and created a new file.

That is one problems with profiles. The CUI is an attempt to take issues away from profiles, but we are finding that there are redundancies.  There are items controlled in the profile, the registry and the CUI and sometimes for one individual thing. Which makes one wonder, why? and which one has the most power. We are learning that the CUI is having the most power.

Another quirk with the profile is that, even if you think you are creating a "clean" version for usage among the troops, you always forget one little thing and have to do it over. Editing the AWS/palette portion of a profile with textpad: I give you credit for even trying! That portion is pretty much written in another language.

Pieter

[KewlToyZ]

CUI, arg, atc, xtp(now obsolete), aws(a really nasty POS), all bouncing up and down in my rubber pajamas and locked down in the registry to code around where they should have toggles or something to allow an easy refresh/update, but noooooo  :ugly:

I have been getting feedback from the guys here that has been greatly appreciated if not a godsend to help me battle the nature of my avatar.

In all honesty the guys at Autodesk have done some really interesting, helpful (if not brave) things attempting to cater to many user requests. If nothing else trying to innovate.

If we could just get them to run through and finalize compatibility with all of the verticals for the next few years it could actually be wonderful.

After all, I am finding the 2008 MEP interface runs better on Vista than XP in many functions even though they denied the installation without hacking the msi file. I cannot blame them for it either with so many complaints lodged against the new OS they had to protect themselves for a bit.

[ELOQUINTET]

I tried to put our stuff on the network when we moved to 2008 and it worked seemingly until i installed the service pack. everything got so messed up and i wasn't getting predictable reults when troubleshooting that i finally abandoned the idea for now and went back to keeping palettes in the default location. Please let me know if you figure out how all of this crap is related and how you get it to work.

[KewlToyZ]

It works on the network, but, one guy (me) handles the updates.
I am the only one who can write or edit the files in the palettes directory as administrator.
Also I always do a double lock by making the networked palettes read only on each atc file.
They can create their own local palettes from the files on the network using Design Center.

They can then send it to me or I can log onto their desktop or drive using unc paths (\\username\c$\TheirToolPalettePath) and copy the files to place into the Palettes directory on the network.
Then I update my workstation, verify the groups are setup properly, then export the new profile.

The only way to enforce an update without ruining their setup is by making the users create their own workspaces.
I created a generic all disciplines Default, a MECH, PLUM, ELEC, Workspace to get them started and familiar.
I also use the Dashboard, it is completely customizeable in 2008, take advantage of it!
You can place many items used on a limited basis in Dashboard and use it along with tool palettes.
By default i dedicated the right side of the environment to docked items for the Properties, XREF's, Palettes, and the Dashboard. This helps leave more actual workspace for the users and I found they looked at it odd the first day, after that they are all using it fairly often in that format.

The networked arg file essentially has to be refreshed locally to do an update.
The way to do this is by renaming their current Profile which has written a version of the networked arg into the registry. This will force their registry to update.
Then the palettes will update.

This can be accomplished by lisp (rename the previous version of the profile (i.e. MEP  to MEP-Remove) and type the command (or run the command the next time they start the interface but this could be problematic if they restart a few times throughout the day.)
Or ran as a filename.reg file (which could be problematic as well since it would fire for everytime they login that day)

It is Probably best to create a lisp called "update" or "reset" and let everyone know they need to run it for the update.
The only thing they would lose would likely be custom fonts and colors in their command line since they have already backed up their workspaces.

The best way I had considered:
Since I have a login.bat file for the Active Directory users, I can make files copy or delete from their desktop.
Naming the MEP.arg file like MEP1.1.arg and simply delete the old and copy a new MEP shortcut Icon pointing to the new MEP1.1.arg instead will do the same thing and show a history of versions in their profiles in case something goes awry you can always revert back.

The only issue with this is if the user has copies of the Shortcut in their Quick Launch or elsewhere, they have to be reminded to over write those with the version on their desktop. Also if they did not restart their machine they will not have the updated icon.

Let me know if you have any issues or questions.