"Customization file 'acad.cuix is write protected" AutoCAD Message on Open

[thephess]

ACAD 2014 has just been rolled out on our network, with the cui files located on a write protected drive. Every time the users initiate the program they receive an AutoCAD message re: "Customization file 'acad.cuix is write protected". Most users only need to check 'OK' once whilst I need to check it 3 times before the program initiates, by the way I do not have write access to the drive where the files are located. My query is can this message be turned off and if so how? I can then pass the knowledge onto our ACAD administrator.
Cheers,
thephess

[Steve.Mazza676743]

It sounds like the "Main Customization File" is pointed to the read-only network location. That's not the right way to do it. If you want certain things to load all the time and be safe from accidental damage, then make that the "Enterprise Customization File" and put it in a protected location. Point the "Main Customization File" to each user's C drive. That lets the users modify the Workspace so they can configure their toolbars and command line in a way that works well for them. At the same time, they can't accidentally unload things from the Enterprise CUI.

What goes in the Enterprise file and what goes in the Main file is a decision that will have to be made for each firm. You could set it up so that everything used by anyone at the firm is in the Enterprise CUI (or is loaded as a partial CUI, by order of the Enterprise CUI). Then the Main CUI can pretty much be blank except for containing the user Workspaces. On the one hand, this setup will make all the modules anyone could possibly need available to every user. And it is less work from a management perspective. On the other hand, loading everything may bog down some users' machines unnecessarily.

Or you could set it up so that the Enterprise CUI file has only a few custom firm-specific elements in it, and the Main CUI file will determine what modules load on a user-by-user basis. This could optimize program performance by leaving the program in a bare-bones state for the people that won't use every module. But it could result in more support calls if users break stuff.

Honestly, I think the issues with MNU corruption are very much reduced in the last few releases. The CUI files seem to just work. Casual users won't even know what a CUI is or how to edit it.

[BlackBox]

1+

Main CUI should be write-accessible.

Enterprise CUI is read-only by default within CUI Editor but a simple LISP can store Main CUI, and swap Enterprise CUI as Main then open CUI Editor so Enterprise CUI should also be stored to read-only location (if that's a big deal for your office).

MNU files are rebuilt when CUI is updated; for example when an Autoloader .bundle includes CUIx, it is replicated to local ..\Support\ folder where MNU for each light/dark is generated as well... I still feel that CUIx should instead be loaded from said app .bundle, rather than produce such 'residue', but that's another topic entirely.

Cheers