Federal Security and SolarWinds product installs - what are your Top 3 problems

Happy New Year to all.  And let's try something new.

Many Fed customers (especially DOD) have to document exceptions made to their security settings in order for various SolarWinds products to be installed and configured to work.  Can you tell us your top 2 or 3 items that cause this type of "friction" during the installation of SolarWinds products?

For example: before NCM version 7.2.0 many DOD customers had to document and get approval for a DISA STIG Category 1 vulnerability exception in order to run automated jobs - even the critical daily config backup.  The root cause was that NCM (before V7.2.0) used Windows Task Scheduler for automated jobs; and Windows Task Scheduler required the storing of a user name and password in a way that apparently is not very secure.  So disabling the Microsoft Windows Task Scheduler on the NCM server disabled the automated backup of configurations.  If you use NCM then you know the automated daily/weekly backups is likely the key reason to use it, so clearly this was really bad for NCM customers.

Several customers reached out to SolarWinds to ask us to fix this security vulnerability to "reduce friction" during the installation / implementation process.  With the release of NCM 7.2 last summer this problem was resolved.

Another recent example is the type of DB connection caused "friction" for a DOD customer.  Apparently connecting to SQL Server via "Windows Authentication mode" is a compliance requirement, while NCM requires the use of "mixed mode authentication".  So the customer has to document the exception, get it approved, etc...

This might open a big can of worms, but for those of you that are Federal IT professionals, what are the top 2 or 3 issues that cause friction when installing SolarWinds products?

Feel free to send me a private message if you don't want to make your issues public.


  • Digging around my SolarWinds modules and databases to change service account passwords is particularly painful.  Sometimes it's tough to be sure the account I want to change is the one I really the one I am looking at in the user interface.  I have a large number of service accounts and I work with different teams for managing each account.  I realize that changing credentials via config wizard works, but this also introduces disruption.  Displaying all accounts configured in SolarWinds in one place would be immensely helpful.  Presumably running the config wizard would be required for some of the credentials.  Sorting the credentials by app and perhaps also sorting by the need to run the config wizard would be helpful.

    Even if it was limited to one place per module, this would be useful.  The alternative (digging around in database tables) gets really cumbersome.

    Second idea:

    Granular Access Control on Node by Node Basis


  • do9h,

    Thanks for both of your items.

    1. Changing Service Account Passwords in SolarWinds modules:

    OK, that is a new issue for me.  Having to change credentials in different places in the product when service passwords are changed.  I'll bring this to the attention of the Product Managers.

    Do others have this same pain point?  How common is this?

    2. Granular Access Control on Node by Node Basis

    I see others have voted on this feature request already.

    Do other Fed users have the same issue?  You can vote (see idea link above).  And you can reply here or let me know privately so I can represent your unique needs to our Product Managers.