For posterity:

On a minimal security install unauthenticated access is the only authentication method enabled for most services. We document the risk of modifying roles for UnknownUser (used for unauthenticated access) and cover some other security considerations here:

https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_tighten

If you end up in a situation where your security settings no longer allow you to access Caché, you can use emergency startup mode as documented to log into Caché and fix your settings:

https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_secmgmt#GCAS_secmgmt_emerg

Much appreciation to my colleague Jon who walked through these steps with Joshua.

Hello Zdeněk,

The answer to your question probably depends on the specifics of what you are trying to do and what your constraints are. Is there any consideration to combining the two installer manifests into one? In your previous post you mention an unattended install, so I assume this is related to the .cmd file you are attempting to create. I wasn't aware that an unattended install could run multiple manifests; is that possible or are you running the second manifest manually?

You could use conditional <If> tags in the installation manifest if you wanted to perform some verification. You could use <Invoke> to run whatever method you want to confirm that your first manifest was carried out. For example, you could write and import a simple method that leverages $SYSTEM.OBJ.GetClassList to check that your classes exist. If your method isn't able to run that would also be evidence that the first manifest did not succeed.

https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25SYSTEM.OBJ#METHOD_GetClassList

%SYS.Namespace.Exists would confirm whether a namespace exists.

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=ITECHREF_namespace

Alternatively, you could use the <Log> functionality of the installer manifest and then read the log.

Hope that gives you some ideas! I did see that Dan Kutac replied to one of your other posts - it seems like he is working with you on your manifest so I think he would be able to help you with this.

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GCI_manifest

I would caution against using the management portal to rebuild indices on a live system. Please see the word of warning from the documentation you linked:

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GSQLOPT_indices#GSQLOPT_indices_build_smp

"Do not rebuild indices while the table’s data is being accessed by other users. To rebuild indices on an active system, see below."

Further along on the page you can find more information about safe index rebuilding practices on a live system. I would recommend sticking to %SYS.Maint.Bitmap as that is safe to run on an active system.

Hello Stephen,

That documentation you linked to put you on the right track! If you click on the %SYS.Maint.Bitmap link it will take you to the class reference which contains some examples of how to run the bitmap cleanup:

https://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25SYS.Maint.Bitmap

eg.

d ##class(%SYS.Maint.Bitmap).Namespace("Samples",1,1,"2014-01-17 09:00:00")

d ##class(%SYS.Maint.Bitmap).OneClass("BitMap.Test",1,1)

This utility was only added to the product around version 2015, I believe. It should run automatically as part of an Ensemble message purge. If you need to perform this maintenance on an older version, rebuilding the index can be done though this is a more involved process, especially on a live system.

If needed, you can reach out to the WRC who can provide a utility that performs a similar function to %SYS.Maint.Bitmap for older versions.

Hope that helps!

If you see an error message in brackets, this documentation would be a good place to look to find out what it means:

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RERR_system

<FILEFULL> can indicate issues with the actual disk filling up, but you can also run into it if you have configured and reached a maximum database size.

You can check that setting in the management portal at System Administration > Configuration > System Configuration > Local Databases, or you can use the ^DATABASE utility as documented here:

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_chui-mgmt#GCAS_chui-mgmt_database