This has specifically been an issue with the most recent 2 PI AF Services installers.
What do you mean by changing or deleting service accounts password? The password get's changed or deleted in services.msc or AD ? How are you discovering that the password has been changed or deleted?
I'm not aware of this issue, and I couldn't find any work items or other Tech Support cases.
Sebastien, Check out the notes from OSI TechSupport Case # 867287. I suspect that part of the problem with the passwords is user error (user=me). However, the tech support agent on that case was able to reproduce my problem.
Sebastien, below are the details of the 2 issues I am experiencing with the AF Services Installer:
1.) When running the PI AF Services 2017 R2 Update 1 install kit, if the install kit is in modify mode and gives you the option to configure the accounts services are running as, the install kit by default has the password option blank. Then if the user selects modify to continue the installation, the services will be stopped by the install kit, the install will proceed, and then install kit will try to start the services back up. Any service that was previously running as a custom service account (non NT Service account) will not be able to start due to a logon failure.
2.) When running the PI AF Services 2017 R2 Update 1 install kit with the AF SQL script execution feature selected, the user running the install kit must be a local administrator on the machine running the SQL server. If the user is not a local administrator on the SQL machine the install kit fatally fails when it tries to create the AFServers local group. This failure happens even if the AFServers local group already exists on the SQL server.
1 of 1 people found this helpful
Thanks for the information!
1) Ideally the services should be manually stopped before running the installation kit. This is mentioned in the documentation, specifically for the AF Service here:PI Server
The installer needs to stop the services to perform the upgrade. The installer by default assumes that the same service accounts will be used. The installation should proceed successfully if you are not changing the service accounts without you requiring to re-enter the passwords. We've communicated to the developers in charge of the installer that the default of having a blank entry for the password leads to confusion. The developers responded that the UI may be improved in a future version. At this point in time, I don't have more information as to what the changes will be and what's the target version. In my system, I just ran through the installation process and the services successfully started using custom service accounts. I'm thinking there is something different that we are doing, but I'd need more detailed steps to try and reproduce.
2) The documentation is lacking with respect to this. It is required that the user running the installer, if they are to upgrade the SQL Database on another node, be a local administrator of the SQL machine. This is true for both installs and upgrades. The reason is that the installer needs to be run with a user that has rights to create or modify local groups. In the past, for upgrades, this requirement wasn't technically needed if the group was already created and was not modified in any way. In 2017 R2, there are some modifications done to the local group, notably that the description changed slightly, and consequently now the requirement to be a local admin on the SQL node is technically needed as the installer will modify the local group. We will be updating the documentation so that this is clear: if the database is to be upgraded from the installer the user needs to be a local admin on the SQL Server and have the appropriate rights in SQL (doc:PI Server ) If the user running the AF installer is not a local admin on the SQL node they will only be able to upgrade the application service. Another user with local admin rights, and the required SQL rights will need to create the local group and upgrade the database using the go.bat. In short, what you experienced is expected.
Hope this helps,
1) I ran the installer with the services already stopped. It still failed.
- I have run the installer without making any edits to the service account configuration.
- And I have run it using the service acct that was populated by the installer, but adding the password (which appears to be blank.)
- And I have also used the "browse" option to specify the domain service account, while also adding the password.
In all of these instances, the installer reports that it is unable to start the AF Service. And in all of these instances I find that, indeed, the password is broken for the AF Service service account and I am required to use the services control panel to restore the correct password in order to restart the service.
2) Working in our development environment today, I was added as a local administrator and also as a SQL "sysadmin" on the SQL server. But, running the AF Services 2016 R2 installer from the PI AF Server, the installer fails. It seems to keep failing for the same reason that it was failing with the 2017 R2 Update1 version of the installer - when attempting to create the AFServers group on the SQL server.
Note that none of this is an issue if the SQL Upgrade scripts are run by a SQL admin on the SQL server prior to running the upgrade insaller on the AF Server. And this is exactly what we are trying to avoid. The SQL admins have elevated permissions that could possibly allow the upgrade scripts to affect other databases on the SQL server. It would be a much more controlled and secure process if the PI Admin could update the PIFD database with only the privileges required for that database. Doesn't that seem reasonable?
1 of 1 people found this helpful
Thanks for the detailed info.
For (1) Caleb Steiner was able to reproduce in his system. We're bringing this up to our AF developers attention. This only seems to happen if the install is modified from the Control Panel and this does not happen on a fresh install or upgrade. We'll continue the troubleshooting in the Tech Support case, but we'll be sure to come back to this thread with the final conclusion/solution.
For (2) It is very odd that the installation would fail if you are a local admin and have sysadmin permissions in SQL. I'm suspecting that you are running into a known issue with the installer prior to 2017 R2. The issue was that the installer and go.bat did not support a port number in the SQL Server name for connection. You'll notice the following error in the install logs:
Calling custom action OSIWixExtension!OSIWixExtension.CustomActions.CreateAFServersGrp
try create group
The network path was not found.
This issue was resolved in 2017 R2, WI number is 163583: https://techsupport.osisoft.com/Downloads/File/14cbd50e-4880-4eb9-947d-6edb4a0d9048
During the AF upgrade, it is not required to have sysadmin privileges in SQL, only db_owner. This is mentioned here in our documentation: PI Server
If the SQL Scripts are to be ran remotely, it is required that the user has local admin rights on the SQL Server to have the required permissions to modify the local AFServers group. This is because the installer assumed the AFServers group will be mapped to PIFD with the db_AFServer rights. By default, the local administrator group has no rights in SQL.
In short, for an upgrade the PIAdmins only need db_owner rights to PIFD in SQL, but need local admin rights on the SQL Server node if the scripts are to be ran remotely. If the user did not have local admin rights, and the AFServers group did not exist, as the install is currently designed, it would successfully install the AF Server, but the service would fail to connect to SQL as the assumption made is that the local AFServers group is mapped in SQL to PIFD.
I hope this clears things up. I'll be bringing this post up at our weekly meetings with the AF developers.