How to Change your Admin Password and Keep Fourth Shift Running

Have you ever changed your admin password for whatever security reasons and then all of the sudden you cannot print out Fourth Shift Reports, FSTI is no longer working, add on products from other vendors will not work and you have cash in on your Annual Support (if you bought it), and you just want to hide in a corner because everyone is yelling at you why things aren’t working and manufacturing is down?

The Simple Fix

The simple solution to this problem is to change the password back to what it was and magically things start working again.  However, you still have that possibility of a security threat with that old password whether an employee had to be dismissed, you somehow got hacked, and/or the password you have has been deemed not strong enough by auditors.  We have dealt with many customers that have had the same administration password for over 15 years and it works for them.  But is that the best practice?  With the rise of security risk in the IT world, the obvious answer is no, and that everything must be done to prevent any worst case scenarios to keep your business safe and avoid risk.

Why When I Change My Password, Fourth Shift Issues Arise?

To find a permanent solution, we have to look at the cause.  Why when you change an admin password do things stop working?  Well Fourth Shift has some configurations that have to be updated when you change your password.  However, it does stop there.  There is a laundry list of things you should check and test before you change your admin password on the live system.  Even if you do not need to change your password now, having a plan and knowing what to do in case you do need to make that change is necessary and certainly a best practice.

How Do I Plan for a Password Change?

FS Backup Utility
Figure 1

When you have to a change a password, I know that it can be an urgent need.  However, if you first test the change you can save a ton of hassle and any risk of production downtime.  Most of our clients have a sandbox for Fourth Shift for this very reason.  If you do not we strongly recommend you get that implemented immediately.  Not just for this issue but for training, backups, testing updates and new software ad-dons, etc.

With your Sandbox in place, make sure to do a full backup of the Live Fourth Shift database (FSBDXX) and then run your backup utility (See Figure 1) or use the SQL utility to backup your Fourth Shift Database.  Also make sure that your Sandbox environment is a carbon copy of your live system as far as username, passwords, server version, SQL version, etc.  With everything backed up and running live your live system it’s time to dive and and test your change.   Here is a short list of things that you will may want to check after you make the change and we will go into detail on each bullet point:

  • Fourth Shift SQL Administrator
  • SSRS Data Source
  • Windows Services

This may not be the complete list, but these should get you working before you have to create a ticket with Infor.  Let’s start with the first.

Fourth Shift SQL Administrator

Whenever the administration password is changed, this is usually the first place we look mainly if they cannot export reports into the MFGSYS folder where they mostly are exported.  To find the Fourth Shift SQL Administrator go to Start –> Fourth Shift Tools –> Fourth Shift SQL Administrator.

Fourth Shift Tools

Click on the Fourth Shift SQL Administrator and then expand Fourth Shift until you get to the two letter that designate your Fourth Shift installation.  In Figure 2 it is shown as SB for Sandbox (most live installations are “MR”)

Administrator Console
Figure 2

Make sure to Right Click on the two letter designation (“SB” in the case of Figure 2) and then click on Properties to see what is displayed in Figure 2.  Here is where you want to update that Password you updated IF the password you changed is the same as the login name that is in “Login name:” box.  If the Login Name is different then you should be fine and the reports should still print and export.  IF it is the same (which in most cases it is) you need to fill in the Password and Verify fields with the new password.  Make sure that the domain is in there correctly as well.  For Fourth Shift versions 7.4 and below, you may have to insert the Login Name as domain\username as there is no place for the domain in that version.  Let’s say the domain name for your machine is COMPANY and the username is administrator.  You would fill in the Login Name field as COMPANY\administrator and then process to insert your new password.

Once you have inserted the new password make sure to click on Apply to test.  If the passwords do not match or what you entered does not match what you changes it to, you should get an error.  Otherwise if you do not, click on OK and you should be back to printing and everyone should be happy!

NOTE:  Also notice here that there is a tab for the Data Source.  This is if you change the fsadmin password in SQL.

SSRS Data Source(s)

This can also affect not only your Fourth Shift reports but also your custom SSRS reports.  Why when I change my admin password would that affect SSRS you may ask.  Well the main reason is that you may have subscriptions where reports are emailed to you or members of your team on a schedule and in order to do that you have to store the credentials in the data source of the report.  What usually happens is that the administrator username and password are used for this and embedded either in to the data source or into the reports themselves.  Now if there in the reports themselves you have some work to do to test each report and check it’s properties.  If the credentials are stored in the data source this can be a quick and simple fix.  First navigate to your SSRS report server and it should look something like what is in Figure 3.  If you are having issues finding your report server check out this article for further assistance.

SQL Server Sandbox
Figure 3

You should see a Data Sources Folder like in Figure 3.  Click on that folder to see your Data Sources as shown in Figure 4.

SQL Server Data Sources
Figure 4

Once you see your data sources, click on the Data Source that runs your reports.  In the case of Figure 4, there is only the one data source “FSDBSB” that runs our custom reports.

NOTE: For the data source of the Fourth Shift reports you will have to look in the folder where the Fourth Shift reports themselves are located.  In our case this is located in the “Sandbox” folder from Figure 3.  DO NOT CHANGE THIS DATA SOURCE!  The reason is that you did that in the previous section in the Fourth Shift SQL administrator.  If you are still having issues with the Fourth Shift reports either contact your Fourth Shift consultants or create a ticket with Infor.

Next click on the data source to show it’s properties as shown in Figure 5 below.

Data Source Properties
Figure 5

Here you will see that under the section entitled “Connect Using” that we have the credentials stored by a specific user that has full rights to the reports and in this case it is the administrator account.  You can see where this can be an issue if the password is changed.

If you have the same configuration as in figure 5 you will have to update that password.  Make sure that the radio button next to “Credentials stored securely in the report server.”  Then, insert the new password in the “Password” field.  Also make sure that you check the box next to “Use as Windows credentials when connecting to the data source.”  After that, click on the Test Connection button to make sure the connection works.  You should get a message with green letter under the button saying that the connection was successful.  Otherwise you will get an error in red letters.  Once you have successfully tested make sure to click on the “Apply” button and your reports should be good to go again.  For more information on storing credentials in a data source, check out this Microsoft document.

Windows Services

The majority, if not all, of Windows Services that run Fourth Shift such as MAIN, FIN, Fourth Shift Remoting Service, Lockserver, etc., run off of the local account for credentials.  We have seen in some cases some of these services have the administrator credentials stored for some services to work.  To check this, navigate to Windows Services as seen in Figure 6.  To do that go to Start –> All Programs –> Administrative Tools –> Services.  If your server does not have the same configuration as in Figure 6 this article from WikiHow can show you how to find windows services on your particular server.  Also make sure you are on the server that Fourth Shift is installed.

Figure 6

Once you have found your services page, scroll through and look for the MAIN and FIN services.  These services will be names MAINXX and FINXX with the XX equaling the two letter characters that you assigned to your Fourth Shift instance on the server you are working on.  In our case you can see that the service on our server are called MAINSB and FINSB displayed in Figure 7 with “Fourth Shift SQL Service” in parenthesis after the service name.

FIN and MAIN services
Figure 7

First make sure your FIN and MAIN services are running.  If not, right click on the server and click on start.  I can’t tell you how many times that has saved IT from pulling their hair out and opening a ticket with Infor.  Usually a restart resolves but before you do so it doesn’t hurt to check these services if Fourth Shift is down.

From here you can see if the service is logged on using either a Local System (default), a Network System, or a log on specified in the service under the “Log On As” column.  If this is true of your instance then you should be good to go.  If not, you need to double-click on the service and then click on the “Log On” tab (Figure 8) and update the password.  As I mentioned before this is a rare occurrence but I have included this because there have been instances where a service for Fourth Shift or third-party software meant to work with Fourth Shift use a different log in as the Local System account.  The reason for this in one instance can be that the software for this service needs access to printers across the network and the Local System account does not have access to do so.  This is true of our Fourth Gear Queue Software that allows automatic printing or emailing of reports and/or labels from data collection, purchase order, estimation, or other software.

Services Properties
Figure 8

So if you changed your password then hopefully we have you back up and running.  If you are thinking of changing your administrative password or if you haven’t changed it in a while (2 + years) then it is good practice to test that change before you make that change in production.  Please leave a comment below if you liked this article or have further questions about it.  If you are having either issues with your Fourth Shift installation or just have general questions and want to talk, fill out the form below and we’ll get back to you.