Have Questions?

November 7, 2019

Support Series: Mount Disk Error

KeyMark Support Blog

By

Matt Parker

Categories
Archives
Read Time: 4 minutes

With any kind of software solution, there are times when issues arise that require help from experts. The KeyMark Support Team ensures that organizations have the tools they need to keep their systems running at peak efficiency, helping them assess, troubleshoot and resolve any technical issues they come across. In the Support Team Series, we’ll take a look at some of the most common issues customers face, and discuss some tips towards resolving these issues quickly and effectively.

One of the most common errors the KeyMark Support Team sees relates to OnBase being unable to “mount” a disk group. This error usually means that OnBase cannot properly communicate with the file location where the disk groups are stored. The error occurs when attempting to retrieve or import a document, either manually or by a process. Here are two examples of what the error message can look like:

 

 

 

Solving the Problem 

Below are some questions that KeyMark Support will ask when this issue arises:

How many users are affected by this?

This helps us narrow down if it is related to a single user profile/workstation or an entire user group/network.

Can the affected users browse out to the file location of the affected disk group?

This is the most common culprit. If the user cannot browse out to the file location of the disk group, that almost always means that they have not been given Windows permissions to the disk group. Most companies have a dedicated user group specifically for OnBase that has access to the disk group. However, if your App Server uses Impersonation – meaning a single user reads and writes to the disk group on behalf of the users – you will need to browse to the file location using that impersonation account. You can find the file path for the affected disk group by going to OnBase Configuration | Disk Mgmt. | Disk Groups | <Select the affected Disk group> | Volume Information | Read Only | Platter Path

Has there been a change of any kind to the system?

We have seen instances where companies have made system changes like moving domains, changing passwords, or migrating disk groups, and sometimes they leave a step out of the process for the OnBase side of things.

  • If there has been a password change to the account running the App Server or the impersonation account, the password must also be changed within IIS to reflect the new password.
  • If there has been a domain change, be sure the OnBase user group exists in the new domain.
  • For changes made to a disk group, such as pointing to a new location or creating a new disk group, an IIS reset must be done to push the changes through. We always recommend doing an IIS reset in production after hours as this will kick all active users out of OnBase and their work will not be saved.
Can the affected users open the OnBase.ID file?

The OnBase.ID file is located within every disk group and references the Disk Group ID and the volume number. If access to this file is denied, or it is missing, you will get the Mount Disk error.

Is there network connectivity between the App Server and wherever the disk groups are stored?

If the App Server can’t even find the file server, or SAN, it will automatically assume the disk groups are not mounted.

Are the permissions on the disk groups configured correctly? 

Sometimes, the Share/NTFS permissions on the disk group have either been changed or were never set up correctly. Below are the permission requirements from Hyland to properly access the disk groups.

  • Client document retrieval
    • Share Permissions: Read
    • NTFS Permissions: Read & Execute (List Folder Contents and Read)
  • Client Document retrieval with Import and Processing
    • Share Permissions: Change
    • NTFS Permissions: Modify (Read & Execute, List Folder Contents, Read, and Write)
  • Application server – This account will either be the impersonation account used on the App Server, or the identity account running the application pool for the App Server, if you do not use impersonation.
    • Share Permissions: Change
    • NTFS Permissions: Modify

While these are the most common issues we run into, they are by no means all of them. If none of these suggestions resolve the error, or if you would like someone to go through these with you, always feel free to reach out to the KeyMark Support Team.

What You Can Do Next:

Leave a Reply

Your email address will not be published. Required fields are marked *

What's on our mind?

June 1, 2020

Contact Tracing and Case Management

Read More

May 28, 2020

How to Uncover the Hidden Cost of Paper in Healthcare

Read More

May 20, 2020

Process Intelligence Helps Hospitals Gain Efficiency and Save Money

Read More

April 22, 2020

Getting the Most out of RPA with Reusable Bots

Read More

April 8, 2020

KeyMark’s 5 Minute Rule

Read More

March 28, 2020

The Orange Chair Podcast, Episode 4: Automation in Government

Read More

March 18, 2020

How to Choose an Intelligent Automation Reseller

Read More

March 16, 2020

RPA at KeyMark: How We’re Using Digital Workers

Read More

March 13, 2020

The Orange Chair Podcast, Episode 3: Automation Assessments, Benefits and Discoveries

Read More

SHARE
Share on facebook
Share on twitter
Share on linkedin
Share on pinterest