Best way for a design office manager get office under control

Hi Guys

I'm a fairly experienced design office manager who has taken a new role.  There are ~20 drafters using a mixture of V8i, SS2 and SS3, AutoCAD and Solid works.  All the resource files are installed locally (C:). I have seen two different license servers so far (select server).  Everyone has created there own text styles and cell libraries etc.

I have Bentley CAD admin training and ~12 CAD programming/ drafting experience.  I'm setting up a network build but experience tells me that implementing the change through instruction will be an uphill battle.

I've done this before but never with such a fragmented system, Would love to hear from others who have managed something similar.

Any ideas on how to get notification if a user is still using their own build?  or force users to use a particular build?  

Parents
  • Hi Michael, there are ways to lock out users customisations and force people to use the company build. I've done this quite a few times and part of the reason I developed the hta interface for my custom builds. If you'd like to know more feel free to have a look at my blogs.



  • Gday Bear. I've written Vb scripts and auto run macros to achieve very similar. The HTA looks interesting but I just can't learn another language because my head will explode, seriously they are all kinda merging in my head.

    The problem is how do I interact with an install that is completely local? Shut down the license server and hope they haven't checked licenses out?
  • Personally, I would avoid editing ANY delivered cfg files. Cfg files placed in the appl directory can also be distributed by login scripts if needs be.



  • Bear and I disagree strongly on this point - I also use a custom mslocal.cfg file to redirect the users to a network workspace.

    IMHO, adding a file to the appl folder is really no different that editing the mslocal.cfg.

    Many items in the delivered CFG file use the : operator, which allow them to only be assigned if the variable is undefined. I found that to get in my definitions in front of many of these, the mslocal.cfg file was ideal. Its a technique we used back in the CLIX and DOS days and has served me well. Bach then, on CLIX, we assigned paths based upon departments a user belonged to in a custom cfg file. On DOS, there was a local.cfg file that contained settings for video cards and digitizer tablets.

    We have multiple clients with multiple workspaces. I have used client based PCF files for close to 20 years. Some of that time, the client.pcf files set up all client specific variables and paths and we also use project specific PCF files to point folders to the various project specific folders. The last lines of these files used a %include to include the client based PCF files to complete the process. Users could use the generic client PCF files if asked to review files from the client that had no project folder, or during initial work while the project was in its startup phase. Once the project.pcf file was created, they could start using it.

    My current office does not use any project specific PCF files but we do use a VBA macro to assign values to placeholder variables assigned in the other CFG files. A number of our clients use VBA macros as part of their workspace, so if a user changes clients, we also have code to walk through the list of vba autoloads and confirm if a loaded VBA is in that list. Any that are not in the list are then unloaded.

    And I have used a single network workspace since V8.5 through V8i Ss4. I found many new variables do not effect older files and in some cases, only load certain variables after testing for the version. This allows me to add certain DGNLIB's only under certain versions. I use the variable _USTN_PRODUCT_FULLMARKETINGNAME to confirm the actual version, defining a much shorter variable for use in further testing.

    This technique works for us and one of its biggest benefits is that no matter how a file is opened, it uses our workspace. It might not be the correct client, but all of my users learn very quickly that using the wrong client will result in files with missing fonts and linestyles and often missing the workspace tools needed to do their tasks.

    We even keep the UCF file on the network, but allow things like UPF files and some of the other "Documents & Setting" files to reside in the default local location.


    Charles (Chuck) Rheault
    CADD Manager

    MDOT State Highway Administration

    • MicroStation user since IGDS, InRoads user since TDP.
    • AutoCAD, Land Desktop and Civil 3D, off and on since 1996
  • Thanks CADCOP.  I've tweaked users mslocal in the past, but I had the power to almost instantly undo if it went balls-up.  Our current IT is "outsourced" so roll-out / roll back could be a two week turn around.   Also creating a VBS rollout script to edit a file is harder than one that just plonks a cfg file in a directory. 

    Bear - are all the cfg files in the appl directory processed by default? Or do I need to put an %include statement somewhere?

    Best solution so far is if I can put a new cfg file locally using a vbs startup script rolled out by IT.  The cfg would only contain an %include statement pointing to another cfg file on the network. Then in the network cfg I can make changes in real time.   If the wheels fall off completely I can just delete the contents of the network cfg.  

    I think I have a way forward.  

    Now i need to work out all the possible install locations and write the vbs script to find them. Do you know if Bentley has the list of default locations?  Then I could avoid seaching all C:/programsfiles.  

  • 'Bear - are all the cfg files in the appl directory processed by default? Or do I need to put an %include statement somewhere?'

    They are processed by default as are those set by the location _USTN_SITE. Connect does similar with the new variables.



Reply Children
No Data