First, before any of this I'd be running arsmaint -v (cache validation) and address - or at least document - any errors it reports.  I'd get started on doing this in prod now -- it can take a lot of time to repair manually.

For step 4/5, you don't need to rename the logical volumes, just mount the new lv at the old mountpoint.

And, of course, run the cache validation again as part of Step 7 while you're doing end-user testing.

Otherwise, the plan looks good!

-JD.

Just throwing this out there...  It may be far easier to just use arslog to process log messages on the CMOD server directly, and send notifications via eMail or to an enterprise monitoring solution.

-JD.

Only improvement I'd suggest is an if-statement that checks to see if the new filename already exists.  Otherwise, you have the same issue as arsdoc -- it will happily overwrite any existing file with a different file that has the same metadata.

Again, if you can do some pre-checking on your metadata to ensure there's only one document for your criteria, then you avoid the whole issue.

Otherwise, I'm glad to see you got something that works, and thanks for sharing your solution!

Take care.

-JD.

If you want custom filenames, I think your best bet is to do that after the fact with some custom code.  Writing it yourself allows you to do more error-checking, since arsdoc will silently over-write output files if you happen to have multiple documents with the same metadata.

If you can confirm that's not an issue, I think you can use field names in parenths to get what you want:
  arsdoc <options>   -o "(consignmentnr).(reportdate)"


-JD.

Ah, yes -- I see what you're doing now. 

Try adding the query restriction to the User/App Group via the Admin GUI, then do another export -- that will show you how CMOD expects a query restriction to appear in the XML -- then you can try to modify a different account.

But as I said before, it's better to assign these permissions at the group level, so it's easier to understand what permissions a user has by simply reviewing the groups they belong to.  It also allows for simplified administration through your Identity and Access Management team -- adding and removing users from groups in Active Directory / LDAP will change their permissions in CMOD if LDAPsync is configured.

-JD.

You need to specify the Application Group or User Group that you want to apply that query restriction to.

As a matter of good governance, all permissions should be administered at the Group level, and users added to and removed from Groups in order to grant or restrict or deny access/permissions.

-JD.

Hi Lincoln -- as you've already discovered, it's very complicated...

You need to match a user to the groups they belong to, and then the user groups to Folders, and then to specific Application Groups and Applications -- and there might even be query restrictions involved which further reduce the pool of data an individual user might have access to.

In the past, I've had to manually copy access privileges between servers, and it was a real challenge to get everything working properly.

I'll go through some old scripts / notes and post some SQL that might be helpful.

Hi Grahaj & Lars.

There's no real standard for what the various return codes mean, it's up to the developer to define them for each utility.

I'm guessing that in this situation, I'm guessing both 3 and 768 are warnings.  I'll test out this specific situation and see if I can narrow it down.  Both 3 and 768 are peculiar numbers, as they translate to 0000000011 and 1100000000 in binary, so the return codes might be different based on the 'endianness' of the CPU/OS.

-JD.

Yes.  The snag is that encryption happens at load time -- all new documents will be encrypted, but old documents will remain un-encrypted.  You can reload the documents to force the data to be encrypted at rest.  This also remains true for Globally Unique IDs and Hash values -- only new data will receive the features.

-JD.

There's a few reasons not to do this...

- The file it generates may be *enormous*, especially if the loaded files were compressed.
- Older versions of CMOD had issues generating generic index files over 2GB in size, rolling over the byte offset back to 0.
- Loading a single large file with data that spans years may break expiration processing, especially if the expiration type is 'Load'.
- Any error retrieving data from CMOD will result in the entire extract failing.
- If there's more than a couple thousand documents, you'll quickly reach a point where your filesystem will be overwhelmed, and simple commands (ls / cp / mv / rm) will take several minutes.

Most folks extract by Load ID or date or by a mostly-unique ID like customer number, etc.

If this is a particularly large job, reach out to me via eMail -- I have a fast & automated extraction utility I use for migrations.

-JD.

Sounds like it would be a good enhancement request.  :)

-JD.

Just a quick note to let you know we were down for a little over 24 hours due to a blackout in the area -- the VM server came back up after power was restored, but the individual VM didn't restart automatically!

We'll be fixing that issue by moving to a small cloud server in the next week or so.

-JD.

Excellent.  I'm glad to see you got the problem resolved.  Take care!

-JD.

That adds some clarity, but unfortunately we still can't answer your question, because we don't know what your site's backup strategy is, and if it relies on being able to access these files to complete a database restore to a particular point in time.  You'll have to determine this with the help of your in-house database administrators and enterprise backup teams.

-JD.

We don't have enough information on your system design to answer the question.  That's not a standard folder name (as per the Installation Guide) so we don't know what's being stored in there.

-JD.