AP_Rundata not updated

[PatrickOnGit]

The table AP_Rundata should contain information about last run and in what environment the database was used. But it is not updated.

[merddyin]

You are correct. I had expectations of leveraging this table a lot more, however the use cases for it never materialized. I've actually used this module in a number of engagements, and each time I have run up against new requirements that necessitated prioritizing other enhancements. I actually had intentions for adding functions to do various database tasks, such as managing enabling/disabling deployment of items, or adding new Task Group definitions, but I've always been the person who was doing the deployments, so it was faster to just update the DB directly.

The one use case that I had present here was for seeing which domain the module was run in last. The idea at the time was that the module could be used in, say, a development or staging environment, and then the whole module could be copied to production to deploy the same elements. In that scenario, I had intended to check on load to see if I needed to trigger a reset, but a reset would really only be needed if you took the module to an entirely new company...you would want the same type of structure deployed to each of your lower environments. Ended up deciding that the more advanced tracking would be better tackled in the central DB version, which is still in the design phase.

[PatrickOnGit]

I think a really important test would be "is this the correct DB for this environment". And raise a loud bell if the current DB doesn't match current AD. You may store a last run timestamp object in AD and the DB and compare. Otherwise things can go bad with multiple operators using this tool to manage AD delegation

[merddyin]

This is why I am working on the new version that will use a central DB. Writing data into the directory is an interesting idea, and I had at one time considered it as a storage medium in place of the DB, but for some reason just about every customer and senior manager type is petrified of the idea of extending the AD schema. I actually have a fully written out and tested schema extension that adds some key attributes used by the framework, in place of leveraging existing ones, as well as adding a new container and some associated tracking items to AD...not replacing the storage for the DB, but augmenting it. So far though, no one will let me deploy it.

[PatrickOnGit]

Yes, Schema extensions seem to be some magic. I developed one to securly store local account passwords. Similar than LAPS, but much more flexible and to be used for all local accounts. Instead of adding information in the Schema, you may use "ms-DS-App-Data" as an object below Tier-0 OU nad add the revision attribute. I think it is important to ensure to use the right Settings.SQLite with the right AD. Otherwise people just get an old copy, missing or containing more OUs or using it from another environment, like from development into production.

[merddyin]

Interesting idea that, though not sure that attribute is on organizationalUnit class. That said, this all goes back to the issue of using a centralized DB vs a decentralized one. The centralized approach eliminates the issue since all module instances in a given environment would theoretically be connecting to the same DB. Without such items being local to the module, it doesn't matter where you get the module, or whether you copy from environment to environment. I suppose it could still be problematic if you are able to connect cross-environment, though this is a bad practice, but much easier to dump one value (connection point) when the domain changes instead of a whole DB (or at least resetting several tables).