Is shared SQL Server scenario supported by Snow? If yes, are there any limitations?
We are interested in scenarion "single Snow Server + shared SQL Server"
the way you described works well.
However, you need to migrate the "LicenseManagerUser" sql user and "License Manager Data Update" job (SQL Agent Job) too. Also have your LicenseMangerUser password ready.
There is also almost* no need to modify the connection strings manually.
For SI, just modify the DB settings using the snowserverconfig.exe. No need to modify the config file itself.
For SLM it can be done using the WebConfigurator.**
*... SLM SMaCC in the current version stores the "default" connection string that can't be changed via the console itself. However, the old ("wrong") default connection can be deleted from the config file (C:\ProgramData\SnowSoftware\SnowMACC\RegisteredPlugins\LicenseManager.xml - just delete the <DefaultSettings> tag there). Then create a new connection by hand. Don't try to delete it via SMaCC - this won't work and will mess things up even more
**... To do so via the tool, you need to enter a SA user/password (needs to be member of sysadmin role) once to change and verify the settings.
Hope that helps,
P.S.: All just notes from the field and to use at your own risk.
what did you mean with "shared"? Snow doesn't need his own SQL Server, two databases on an existing SQL are sufficent.
according to the System Requirements, Snow Inventory and Snow License Manager both have the following database requirements:
It is possible to run Snow products on an existing SQL server with other databases running in the same instance.
Please let us know, whether you need more info.
Thank you for provided information!
The second question regarding sa rights for SQL user. Is it possible to avoid using sa for Snow installtion process (for SnowLicenseManager database).
I know, that there is a possibility to create SnowInventory database manually, before SI5 was installed.
What about SLM? We have a customer, who want to use existing SQL server, but sa privilegies are not allowed (from the security aspect).
A workaround what I see, to use another SQL instance and user with sa privilegies for installation and then migrate this DB to existing SQL server. Or we can also create a database for SLM?
the sa user is not mandatory. An installation can also be performed with an equivalent user. This works fine, but requires awareness during the installation process. Also, please consider to activate the sa user during the installation process and to deactivate it right after the installation.
Thank you for your reply!
What did you mean as an "equivalent" user?
What rights should has this user to perform a successful installation of Snow License Manager?
The main problem is to activate sa rights during installation - "SA user requirement makes us think SNOW might do changes outside database scope, which in turn might impact other databases/systems".
Equivalent user means user must have sysadmin rights during installation and once installation completed you can revoke the sysadmin rights. Only need to keep db_owner.
I hope this clear your doubts.
Yes, it's clear, but unfortunatelly, sa/sysadmin can't be acceptable.
As I mentioned before, a workaround can be the following:
this could be the solution.
After you migrated the SQL databases to a new server/instance, you have to adapt the connection strings, that provide the connection from the Snow components to the database. These connection strings are encryped and have to be decrayted, adapted and encrypted by Snow Support. After that, you can exchange the connection strings by yourself.
The connection strings are located in:
If you have further questions, please don't hesitate to ask!
to migrate a local SQL login like the LicenseManagerUser from one SQL server to another it might be helpful to extract the exact user information including the SID and (encrypted) password from the old database. If you transfer the database from the old SQL server to the new one, the database user will only be mapped to the SQL login if the internal SID of user (database) and login (SQL Server) match, otherwise you will have to re-map them manually.
Microsoft provides TSQL code to install a procedure called sp_help_revlogin which will extract all login data from the old server (help article No 918992). So if you give the information about the LicenseManagerUser to the SYSADMIN on the new server and ask him/her to execute it.
Retrieving data ...