Java Menu Here!        

Technical Support Center

CHECK THE FAQ Page for Common Questions and Answers.


** Make sure you are using the latest ServerBoss version 7.35 **

  • 64-Bit Windows (Version 7.35 or higher has no known issues, this refers to 7.25):

    Version 7.25 or lower ServerBoss Server does not run on 64-bit OS: You must use a 32 bit server for the "ServerBoss Server" (is essentially a data store only). 64-bit regulated/restricted servers ARE supported using a 32 bit Serverboss Server. 

    Version 7.25 Issue with SBSetup.exe:  Windows 64-bit operating systems redirect version 7.25 and earlier SBSetup.exe copying of files and modifications of registry to WOW6432 alternative locations, which results in nothing working after running SBSetup. 

    To manually activate or deactivate ServerBoss Logon Checking on 64 bit windows you must modify your Path and modify the registry AFTER running SBSetup normally:

    1. Modify your path:

    Add  C:\WINDOWS\SysWOW64 to the end of your path in System Environment Path.

    2. Modify the registry:

    Regedit, navigate to:

    HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

    Change the value Userinit by replacing C:\WINDOWS\SYSTEM32\userinit.exe, with Logonchk.exe,

    If there are other entries included in the string, only replace the part of the string as noted above. You must terminate the string value with a comma. Note: C:\WINDOWS\SYSTEM32\ path info for userinit.exe is not necessary unless there is not path set to system32 folder and may or may not be present.

    TO DE-ACTIVATE Logon checking on 64-bit Windows you would have to do the opposite:

    Regedit, navigate to:

    HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

    Change the value Userinit by replacing Logonchk.exe, with userinit.exe,

    If there are other entries included in the string, only replace the part of the string as noted above. You must terminate the string value with a comma.


  • Windows 2003 All Versions Server Issue: ServerBoss version 7.25 or lower requires You MUST manually turn off Windows Server 2003 RDP logon restrictions on all 2003 restricted servers. By default Windows 2003 tries to restrict users to a single session. This feature does not provide sufficient configurability, flexibility, group restrictions or application metering and will stop ServerBoss from operating correctly.  To fix this correct, run Administrative Tools, Terminal Services Configuration, Click on Server Settings and set "Restrict each user to one session" to No.  Do this on all restricted servers or ServerBoss will not work at all!

  • You only need one installation to manage an entire network. Do not install the entire software on every machine.  You do need to run SBSetup.exe on every machine from your share location.  For Citrix ICA and Terminal Services RDP authorization ServerBoss performance works best if your ServerBoss Server is NOT a member server servicing the ICA and/or RDP sessions.

  • Review the help file ServerBoss.hlp documentation to review your setup procedure. Most questions are answered in the documentation.

  • ServerBoss is not configured to run on this Server or Workstation - This can occur if the machine name as configured in ServerBoss.exe, Manage Servers or Manage Workstations does not match the NETBIOS name of the machine.  For example, if you have named your server terminalserverone, the machine name is actually terminalservero or the first 15 characters.  So, you would configure the first 15 characters as the machine name in Manage, Servers, for example.  Otherwise when ServerBoss makes the API call and compares with the name stored in its databases a match is not found.  This could apply to any name, ie Users, Domains, Groups, etc that Windows truncates for NETBIOS compatibility.

  • Upgrading results in License Error when you run ServerBoss.exe the first time. - Running ServerBoss.exe is the last step of the upgrade process. If you get an error DO NOT convert your license to a demo.  Try again from the registered network path, i.e. \\myserver\ServerBoss\ServerBoss.exe.   If you get the error on the LOCAL path only, then you will still be ok if you run SBSetup from the network UNC path too to complete your update.  This will allow you to complete your upgrade process and roll out to all servers.  Then once you have completed your roll out to the new version, have your license file reconciled by a ServerBoss support person by emailing your ServerBoss.lic license file to along with a brief explanation of what happened.

  • "Error occurred #8 -> CANNOT READ FILE" or other license file related errors in DEMO mode only.   For demo mode only on Windows 2000, and Windows 2003 Server users must be "Power Users" or have equivalent NT4 type access to registry AND users must have read/write access to *.ini files in System32 folder on all platforms. THIS DOES NOT APPLY TO REGISTERED SERVERBOSS INSTALLATIONS.  After registering a permanent license you can utilize normal user rights. Refer to our documentation on access to the ServerBoss server files when you have a Permanent License.  If you need assistance setting up your demo or with securing your permanent ServerBoss installation, technical support is available for no charge.

  • ServerBoss does not store user specific files and DOES NOT require "install mode" on Citrix and Terminal Services.  Just run the setup the old fashioned and execute!

  • Make sure you are running the latest STABLE Service Packs for Windows and Citrix as applicable. The following is the minimum level of service packs we recommend:
    Download here!
    * Windows NT 4 - Service Pack 6a
    * Windows NT 4 Terminal Server Edition - Service Pack 6 with latest hotfixes.
    * Windows 2000 Server - Service Pack 4 plus latest hotfixes.
    * Windows 2003 Server - All latest hotfixes from
    * Citrix MetaFrame XP(x) - No Feature Releases Needed, but you should apply  Service Pack 3 plus all hotfixes (see for latest list of post SP3 hotfixes.)
    * Citrix MetaFrame 1.8  - Service Pack 4

  • SLOW PERFORMANCE AFTER Windows 2000 SP4 - This is usually caused by bugs in SP4.  We have posted two non-public hotfixes that fix issues with Terminal Services post service pack 4.  Download and install Download here! These hotfixes are minimum requirements with SP4.

  • SLOW PERFORMANCE DURING CHECKING OF CERTAIN SERVERS,  PRIOR TO Windows 2000 SP 4, in every case has proven to be caused by outdated (needs Service Pack) or corrupt operating system files.  Apply latest NT/2000 AND CITRIX, if applicable, Service Packs to ALL servers has always resolved this.  ServerBoss does not "wait" for servers. During normal operations it should only take milliseconds for ServerBoss to communicate with each server during execution.  If you observe delays you probably have a server that is not running the latest services packs OR some unrelated application install overwrote NT/2000/CITRIX OS DLL's causing your OS problems.  Use Debug Mode and Status Windows to identify the slow server and correct.

  • LONG DELAYS DURING LOGON WHEN RUNNING LARGE NUMBERS OF NT4 TSE SERVERS.   There are known multiplexing issues on NT4 TSE when many requests to a single share location are processed simultaneously.  This is the action that occurs when large numbers of users are logging in at the same time when using ServerBoss.  The issue was partially resolved in NT4 TSE SP4 but not activated by default. You need to activate this fix.  This is based on the Microsoft Article 190162:                                                                  
    SYMPTOMS: To maintain compatibility with existing Server Message Block (SMB)-based products (for example, Microsoft Windows NT 3.x and 4.0, Microsoft Windows 95), Terminal Server's use of SMB has not been modified from Microsoft Windows NT Server 4.0. This can cause a problem if many Terminal Server users connect to a single network share, either on the Terminal Server or elsewhere on the network. The potential problem is an SMB limitation of 2048 open file handles.
    WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

    This behavior has been modified in SP4 to enable each Terminal Server client to maintain a separate virtual circuit. The new functionality is not enabled by default.

    To enable the new functionality, follow these steps:
    Ensure that the server is at or above SP4.
    From the server, run Registry Editor (Regedt32.exe).
    From the HKEY_LOCAL_MACHINE subtree, go to the following key:
    On the Edit menu, click Add Value.
    Add the following:
    Value Name: MultipleUsersOnConnection
    Data Type: REG_DWORD
    Data: 0
    After you make this registry change, quit Registry Editor and restart the server.

    Windows NT normally multiplexes all file requests sent to a single server over one virtual circuit. A locally unique identifier (LUID) and SessionID on Terminal Server sort user account credentials. These identifiers are used to receive credentials from the server for that user. Each request to access a specific file supplies this server credential handle. This enables multiple users on the workstation (really security contexts since Windows NT can have services access the network with different accounts) to share the virtual circuit and have their own security reflected on the server. This is known as User Level Security in SMB terminology.

    The SMB data structures reserve 11 bits for the file handle value. This reserve results in the 2048 files per connection situation. Terminal Server aggravates this problem, as many users may be simultaneously connecting from Terminal Server to the same share. It is therefore easier in Terminal Server to reach the file open limit than in Windows NT.

    Since the limitation is 2,048 open files per connection and all users use the same connection, a file-intensive program may be unsuccessful when the limit is reached. The Server Manager on the server that is hosting the share can display that the files are opened by the Terminal Server's computer name, since files are opened with a null user name even though security is checked through user name and credentials.

    Theoretically, a Terminal Server with 200 users simultaneously using the share would be limited to 10 open files per user.

  • Security Requirements/Recommendations:  ServerBoss "Share", folder and files should be configured initially with CHANGE access for users during testing. After testing all .lic and .log files must have CHANGE access.  ServerBoss.exe AND SBSetup.exe should ONLY be accessible by administrators and users responsible for administering your ServerBoss system; all other users should have NO ACCESS to ServerBoss.exe AND SBSetup.exe.  All other exe and dll programs should have READ/EXECUTE access.  For Demo mode only users need change access to *.ini files in system32.

  • Use the Debug Mode (System Options checkbox) to slow down execution of ServerBoss programs. Delays are added and detailed messages are generated during execution of the programs.  Using the "Status Windows" with Debug mode is highly recommended.  This allows you to see what is going on. For RAS and RADIUS the log files are in the system32 folder on each the RAS or RADIUS server.  Logon and Application logs are stored in your ServerBoss folder and accessible via the ServerBoss.exe Monitor menu option.   If you contact technical support report the last messages that were viewed before the problem occurred or program stopped.
  • For Enhanced Debugging: Under System Options increase the "Timeout" value to 20 seconds or more. You can set up to 50 second delays/timeouts.  This keeps the debug mode information displayed longer so you can read, analyze and make notes if needed. Don't forget to change values back when going to production for best performance.
  • Try making your test user account an administrator to see if security is not allowing access to ServerBoss Share, Folders, Files or system32 located dll's and/or ServerBoss files OR Registry Access is being denied. If you use Application Security (Note: ServerBoss utilizes a number of low level Citrix and NT API dll's.  Contact support if you need assistance with your particular configuration.)
  • Check the Logs under the Monitor menu option in ServerBoss to verify that you have a start end finish entry for each logon or application execution attempt. If not, then it's likely that your configuration is incorrect or you need to reapply the latest service packs for NT/2000/CITRIX, whichever applies. 
  • Errors regarding 16-bit MS-DOS subsystem - machnm1.exe is a 16 bit driver that is called once briefly during execution of some ServerBoss programs when run on the ServerBoss server. We use the 16-bit driver so we have compatibility across all Windows operating systems. Otherwise we would have to supply a different driver for each OS for the few functions this driver is needed for. Machnm1.exe, if needed, is called briefly and then terminates. MACHNM1.EXE SHOULD NEVER BE RUNNING CONSTANTLY. IF YOU RUN THIS BY DOUBLE CLICKING IT WILL STAY RUNNING AND CAUSE SERVERBOSS PROGRAMS TO MALFUNCTION.  FOR BEST RESULTS USE A SHARE PATH TO SETUP SERVERBOSS (SBSETUP).  Machnm1.exe is never used when ServerBoss programs are launched via the share path.
  • SYMANTEC NORTON ERRORS AFTER INSTALLING SERVERBOSS: click here for a copy we made of the Symantec knowledgebase article for your convenience. 
  • LAN Checking Settings:  (We recommend you use LAN Workstation Checking for all LAN logon restriction.  LAN Server Checking is obsolete, but is still available for backwards compatibility)
    In many cases there are multiple LAN sessions for one user under normal use of a workstation, especially on domain controllers. Usually You may be better off not checking domain controllers.  Checking LAN sessions on each server that the user is allowed a LAN session on and add them up to get the total sessions equal to a normal logon in your network.  Before configuring the LAN checking feature, see what the normal user requires by logging in and checking the sessions for the user on the server you are trying to authorize. On Windows 2000, you would right click on My Computer, Manage, drill down to Sessions and there will be the LAN sessions listed for all users. On Windows NT 4, you run Server Manager and click on sessions and there they are. Those are the LAN sessions that ServerBoss is counting and considering. So, it is quite possible for a single workstation to use 2-4 or more legitimate LAN sessions PER legitimate connection. In that case the number of allowed Logons should be set to the number needed for one workstation

  • Version 5.1 LAN Server Checking DOCUMENTATION ERROR: The installation instructions in our help file documentation included a tip for those who want to update LAN workstations using an automated procedure in lieu of having to run SBSetup.exe on each machine.  The 5.1 help file left out one of the three files (logonck.exe) that needs to be copied to each workstation.  The entry from the help file SHOULD have read:

To automate setup on LAN workstations using your favorite workstation deployment system the following is what SBSetup.exe does when you run SBSetup.exe on a workstation: Copies logonck.exe, machnm1.exe and keylib32.dll from ServerBoss installation to workstations' windows folder if Win95/98 or system32 folder if  NT/2000 and creates registry entry key: HKLM\Software\ServerBoss String Value: "Path" value: "\\servername\ServerBoss" or whatever the path is to your installation. Just check the registry entry created when you run SBSetup.exe on one of your servers to be sure you have the correct entry.

(We recommend you use LAN Workstation Checking for all LAN logon restriction.  LAN Workstation Checking requires NO workstation installation.   LAN Server Checking is obsolete)

  • Unable to login to a server after un-installing ServerBoss.  Various error messages possible.  When you login to what was a restricted server, you get an   error and are then logged off automatically.

    Problem: You installed ServerBoss; then added/activated features to a restricted server using SBSetup.   Then you uninstalled the ServerBoss software without first running SBSetup.exe and removing/deactivating active features including logon authorizations per the documentation and popup reminders provided.

    Solution: Use Regedit.exe and Connect Network Registry from another machine to the affected machine and change the following registry value:  

    HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

    Change the value Userinit by replacing Logonchk.exe, with userinit.exe,

    If there are other entries included in the string, only replace the part of the string as noted above.   You must terminate the string value with a comma.


  • Migrating your ServerBoss Server to a new Server:  This is not needed if you are changing "Restricted or Regulated servers".  This is only required if you are moving your "ServerBoss Server".  This server should be a stable file server that has fault tolerance and will is not likely to change it's hardware.  If you do need to migrate the ServerBoss Server you MUST follow this migration procedure.  There are two options for setting up a new server, one is to follow this procedure, the other option, of course, is to purchase a new server license:

License transfer/migration procedure:

- Install fresh copy of latest version you are entitled to run on the new server and run in 30 day demo mode. If your support and software maintenance is current, download the latest version from the website and install on your new server.

- If you want to migrate setup data you may copy over ServerBoss.sdb or any other *.sdb database files, overwriting as needed. IMPORTANT: Do not copy license old file to new server.

- Download from, unpack and run from NEW server's registered local and LAN paths (i.e. c:\ServerBoss\SBDiag.exe and \\myserver\ServerBoss\SBDiag.exe Generate, copy and paste Local and LAN diagnostic codes into a document along with the new registered paths and save for future step.

- Send an email to request a license code to decommission old server and attach your current production serverboss.lic. We use your current production license file to provide you the migrated license file.

- You will receive an email from support with a license code to activate on the OLD SERVER. Activate decommissioning De-Activate ServerBoss license code on OLD SERVER. Email the resulting license file to noting that you have attached your decommissioned license and are requesting new license. Include Local code, LAN code and paths obtained from your new server using SBDiag.exe.

- You will receive your new permanent license file by email within 48 hours of receipt of all of the above requirements.

- If you wish to run both new server and old server during the transition you can run the new server in demo mode during the transition period.

If you need more than 30 days for transition or you have other difficulties or questions with this procedure or running the demo during a transition please let us know so that we may assist you.



Email support with your technical questions.

Fax your questions to ServerBoss support at (703) 273-5724.
Call for ServerBoss support at (703) 591-7118.
Terms & Conditions |  Privacy Policy |  Return Policy