Skip to main content
Older versions of Internet Explorer will not support certain site features. Chrome, Safari, Firefox, and Edge will provide the best experience.

FAQ: Smart Suite Accounts

FAQ: Smart Suite Accounts



Q: "Can I run non-Spok applications on my Spok servers?"

A: Spok does not test or certify Smart Suite applications running with third-party software.

You may run your own scripts / applications (eg shell, python, perl scripts, or snmp checks of your own) to check the server (back up specific files, check process times, check memory, etc), but Spok is not responsible for their installation, maintenance, troubleshooting, or upkeep.

If Spok is unable to determine the cause of a Spok application symptom and it is believed to be caused by a third-party product or one of the aforementioned scripts, Spok will have the customer disable or remove said item or items in order to continue to troubleshoot the issue.



Q: "Can I change the permissions of the Smart Suite solution for additional security?"

A: Spok highly discourages customers from making any changes to the Smart Suite server directory structure or user permissions. The Smart Suite solution is installed with the permissions required to ensure the system accounts have access to their required functions. Changing file or user access permissions will generally have a detrimental impact to the functionality of the software. Recovery of Smart Suite functionality caused by customer-driven changes to file system permissions or user access may result in a billable engagement.



Q: "What are the user accounts needed to run Smart Suite?"

A: Smart Suite is delivered with the following user (operating system) accounts:

  • amcom: Account for Spok PSG and Spok Support system administration functions of Smart Suite Account. Also used for running automated shell scripts.
  • oracle: Account for installation and administration of the installed Oracle product(s).
  • admin: Account for end-user message / page log recovery, reporting, and other administrative tasks. (xxxSee also data retention, recovery, etc)
  • appman: Account for the storage and download of Smart Console configuration files.
  • wpkg: Account for the storage and download of Smart Console configuration files.
  • wpkgclient: Account for mapping a drive to the Smart Suite Linux server in order to download Smart Console configuration files and wav files for Voice with a Smile (among others).

Each of the above accounts are necessary for the successful operation of Smart Suite and its business functions.



Q: "Can I change the passwords or remove the operating system user accounts?"

A: You may change the passwords to a few operating system accounts, but you must inform Spok of the change. Changing all the passwords on a rotating basis may cause connectivity and / or functionality issues with your Smart Console PCs and may result in a billable engagement.

You may remove some accounts only in certain circumstances.

The following accounts *must* be kept:

  • root
  • amcom
  • oracle
  • admin

The following account can be removed:

  • auditor

If you are not downloading files from the server to the operator workstations (for example, you do not have Voice with a Smile and you are copying Smart Console config files or wav files to the PCs manually), the following accounts can be removed:

  • appman
  • wpkg
  • wpkgclient

Otherwise, these accounts must remain open and accessible on the servers. Adding these accounts back later and setting up downloads / Voice with a Smile will be a billable engagement.



Q: "Can I remove the support account and add a new one, or rename it?"

A: The Smart Suite system is not installed on a Linux server as a general-use program in some folder such as /usr/bin/spok/smartsuite at this time. Most of the configuration and source files are in the amcom user's home directory. There are various programs and scripts that run as root that become oracle or amcom for a brief time to perform a function.

The amcom account is required for specific Smart Suite maintenance, similar to the oracle user. The amcom account cannot be removed, renamed, or disabled.



Q: "Since the company is named Spok, why are there so many references to "amcom" (Linux support account, Smart Speech installation directory, and others)?"

A: Although to many people the company named "Spok" may seem like a newer company, the platforms provided have been around for many years. After Amcom Software, SDC, Xtend, and CommTech combined, the collective company was bought by USA Mobility. Eventually the name of this combined company was changed to "Spok" in 2013. Smart Suite was the exclusive purvey of Amcom Software and now refers to a specific software suite within the larger Operator Console and Event Notification solutions offered by Spok. Support for Smart Suite (including Event Notification and the Mobile Connect platform) and Messenger typically originates from the Minnesota office. The server account "amcom" is the general support user for the Smart Suite system.



Q: "What other access is required by Spok Support to support Smart Suite?"

A: In order to provide full support of the Smart Suite solution, Spok requires the following login access to the various third-party operating systems and Oracle database:

  • Linux servers: root access (and others described above).
  • Windows servers: Local administrator access.
  • Oracle database: A user with 'sysdba' privileges.
  • SQL Server: A user with 'SA' privileges.



Q: "Can I change the password for the root user?"

A: The Linux root user is frequently needed to troubleshoot Smart Suite issues. In order to optimize support recovery, it is important that Spok Support has easy access to the root account.

If a customer changes the root password, Spok requests that the new password is provided to support. If you have changed the root password and need to update support, please open a support case to have the password updated.

If Spok support is not proactively provided with the root password, the customer must be able to provide root access to a Spok Support Engineer at any time to troubleshoot an issue (24 x 7 x 365). Any delay in providing support with root access may result in a delay of the service recovery of your critical notification system.



Q: "Can I provide Spok support with sudo access?"

A: As we understand that perhaps your organization has the same root password across all your Linux / Unix servers and you don't want to share that with Spok, we might consider this a possible exception for informing us of the password. However, we must have root access in order to support the system, as stated in the "SYSTEM PASSWORDS" section of the SLE.

Although not recommended, providing Spok with sudo access is an option. If you choose to restrict root access, the absolute minimum access needed for the sudo command would be:

  • vi
  • init
  • crontab
  • service
  • systemctl
  • cat
  • ls
  • cp
  • mv
  • rm

The list of sudo commands may also be different based on your needs. This list may be added to at any time (ie, there may be other commands as well).

Note that if the sudo account does not have the required access to troubleshoot an issue, the customer must be able to provide the root password / access to a Spok Support Engineer to continue.



Q: "I understand the difference between an Operating System account and a Database account. Can I change the passwords of the Spok built-in database accounts?"

A: While possible, changing the passwords of the built-in Smart Suite database users is discouraged nearly to the point of it not being allowed. Many issues will arise if the passwords are changed and the proper steps are not made to ensure the connection of these logins from every application that might use them.

Changing all the default Smart Suite database user accounts (not your user / operator accounts, which you may do via Smart Console / Smart Center and is your or your users' responsibility) on a rotating basis requires extra work on every server to ensure the aforementioned connectivity and functionality and would be a billable engagement.

Changing the passwords of the wpkg and wpkgclient users (operating system and database) on a rotating basis requires changes to each of the operator PCs as well and would be a billable engagement.