DiaWEB Online Documentati…  DiaWEB Manual Recovery for Win…
  
Page Collections
Attributes
Hierarchy
  • RSS Feed

Last modified on 7/27/2018 4:31 PM by User.

Tags:

DiaWEB Manual Recovery for Windows 2012

Pre-Requisites

Instructions

1. Install SQL Server

2. Restore DiaWEB databases

Usually named DiaWEB and DiaWEB_Attachments.
 

3. Install IIS, Asp.Net and WCF

3.1. Open “Server Manager”.
 
For example, by pressing the Windows key + R (to open the Run box) and then entering "ServerManager".
 
3.2. Click on Manage > Add Roles and Features.
 
 
3.3. Click on Next.
 
3.4. Select “Role-based or feature-based installation” and click "Next".
 
 
3.5. Select the Web Server where DiaWEB is being hosted and click "Next".
 
3.6. Check the “Web Server (IIS)” feature.
 
 
3.7. A dialog should have opened. Click on the “Add Features” button.
 
 
3.8. “Web Server (IIS)” should be checked now. Click on "Next".
 
3.9. The following wizard step should be displayed.
 
 
3.10. Check “ASP.NET 4.5”.
 
3.11. “WCF Services” should be already selected. If not, select it and expand it.
 
3.12. Check “HTTP Activation”. And Click on the “Add Features” button in the dialog that will open.
 
 
3.13. Click on “Next”.
 
3.14. Click on “Next”.
 
3.15. Ensure that the components highlighted with green are checked. and that the components highlighted with red are not.
 
 
3.16. Click on “Next” and Install the changes.

 

4. Deploy DiaWEB files

4.1. Download the upgrade package from the FTP.
 
The following is the last version at the present moment, used for Ornish:
 
 
4.2. Unzip the package and move the content to the folder where the files will be hosted (e.g. c:\inetpub\wwwroot\DiaWEB)
 
4.3. Unzip and copy the files from the “Extra_SafeToReplace.zip” file to the folder where DiaWEB will be hosted.
 
These are files that can be used by any installation safely. They are safe to replace as well.
  • /App_Data/compilation.config
  • /App_Data/errors.config
  • /App_Data/machine.config
  • /App_Data/sessionState.config
  • /App_Data/auth.config
  • /App_Data/bindings.config
Notes: auth.config and sessionState.config will be automatically updated by DiaWEB depending of the settings stored in the database. So different installations might have different files, DiaWEB will handle that.
 

Needed for spell checker:

  • /bin/Hunspellx64.dll: file needed for the spell checker
  • /bin/Hunspellx86.dll: file needed for the spell checker
  • /App_Data/en_US.aff
  • /App_Data/en_US.dic
  • /App_Data/huph_en_US.dic
  • /App_Data/th_en_US_new.dat
  • /App_Data/th_en_US_new.idx

Needed for the /Errors feedback page (which is really an internal small app):

  • Errors/Web.config
4.4 See if we have a copy of the app.config file from production (used before for the installation).
 
If we don't have the file, copy one from the App_Data folder in "Extra_Templates.zip". This file can be used as is, but we should probably see if it is desired to change the values for the default passwords.
 
If we use any other copy, we should ensure that it has the following setting that enables reporting of errors to FogBugz:
 
<add key="ReportToFogbugz" value="true" />
 
And only for Healthways Enterprise, the following 2 settings should be configured accordingly:
 
<add key="ReportService2010Url" value="http://SRSS_Server/ReportServer" />
<add key="SSRSFolder" value="DiaWeb.Reports" />
 
4.5. For all installations, except "Healthways Enterprise":
 
Unzip and copy the content in “Extra_AllButHealthwaysEnterprise.zip”.
 
The only file in this zip at this moment is “srssReports.config”.
 
4.6. For Healthways Enterprise and only if the version is 4.16 (current version, on Jun 2018):
 
Unzip and copy the content in “Extra_HealthwaysEnterprise (4.16).zip”.
 
4.7. For later versions of Healthways Enterprise, we will need the last copy of the srssReports.config file from production. If we don’t have it, we could use the file from “Extra_Templates.zip” temporally. If we do this, no SSRS report will be listed in the Reports page though.
 
Note: the srssReports.config file has currently some changes in Dev, so this file in will most probably contain changes in 4.20.
 
4.8. For all installations, except Ornish:
 
Unzip and copy the content from "Extra_AllButOrnish.zip". At the moment it only contains the Web.config file.
 
4.9. For Ornish:
 
We will need a copy of the Web.config file used in production. If we don't have it, we can use the one used for other installations. We'll probably need to configure the setting for the certificate again (see section 9.2).
 
Also ensure that the Endpoint for Quality Metrics (SF36) API is the production URL, not the staging URL:
1:
2:
3:
4:
5:

<client>
...
      <endpoint address="https://www.amihealthy.com/api2/amihealthy.asmx" binding="basicHttpBinding" bindingConfiguration="amIhealthySoap" contract="QualityMetricsSF36V2.amIhealthySoap" name="amIhealthySoap" />
...
</client>
 
4.10. Copy an existing db.config file to the App_Data folder and configure the connection strings on it for the DiaWEB and DiaWEB_Attachments databases. If we don’t have a db.config file, we can use the one in “Extra_Templates.zip” as a template to start with.
 

5. Install Certificate

Only if the site should be available with https.
 
The exact instructions might depend of the trusted certification authority (e.g. verisign) that provided the certificate.
 
 
5.1. Once installed on the Web Server, copy the Certificate Thumbprint to the web.config file and change the certificate type to Thumbprint.

6. Add DiaWEB site to IIS

Make sure we have the bindings for http and https.
 
The App Pool should have:
  • .NET CLR Version: v4.0
  • Managed Pipeline Mode: Integrated
The default values for the rest of the settings seems fine.
 

 

7. Add "Modify" permissions over the App_Data folder

Give the user account that is used in the app pool running DiaWEB permissions to write over the App_Data folder.
 
If the default account "ApplicationPoolIdentity" is used for the DiaWEB's app pool, we should give the permissions to the "IIS_IUSRS" account, as shown in the following image.
 
 
Optionally, as a workaround and only temporally if we suspect this might be failing, we could add the permissions to the account "Everyone", just to confirm this possibility.

 

8. Verifications to do

8.1. Ensure that reports are running by testing one, for example "Referral List".
 
In order to run reports, DiaWEB needs "modify" permissions over the App_Data folder. See section 7.
 
8.2. Go manually to the following URL: /Error/Test
 
This will throw an internal error and you should be redirected to a Feedback page to send the error to FogBugz. We could then:
  • Verify that sending the error to FogBugz works.
  • Verify that the "testing" error appears in /Errors/List
If any of this is failing:
  • We might need to verify DiaWEB has "modify" permissions over the App_Data folder. See section 7.
  • We might be missing any of the files contained in "Extra_SafeToReplace.zip", like:
    • /App_Data/Errors.sdf
    • /App_Data/errors.config
    • /Errors/Web.config
Or the connection string to connect to the errors local db in the db.config file:
 
<add name="errorLoggingConnectionString" connectionString="DataSource=|DataDirectory|\Errors.sdf" providerName="System.Data.SqlServerCe" />
 
8.3. Load a patient and then the Documents page. This should verify that DiaWEB is being able to connect to the DiaWEB_Attachments database successfully.

 

8.4. Only for Ornish:

  • https://diawebornish.healthways.com/API/v2/Ornish/Referrals.svc

This will test that the REST API service is running.

  • https://diawebornish.healthways.com/API/v2/Ornish/Referrals.svc

This will test that the SOAP API service is running

8.5. Only for Healthways Enterprise:

  • Test a SRSS report
    • Relevant settings to connect to the Reporting Services Report must be configured in the app.config file.
    • The account used to run DiaWEB's app pool must have the permissions to connect to the Reporting Services server.

 

9. Additional Troubleshooting

9.1. For any error that occurs in DiaWEB, we can see if more details about it and possible explanation appear in /Error/List

Additionally, we can also see if more details appear in Event Viewer in Windows. This will be the case on a major failure (missing .config file, unable to connect to the db, etc.) or if the error occurs before DiaWEB can do its basic initialization.

Optionally, and only temporally, we can also disable the error reporting tool DiaWEB has with the following setting in errors.config:

<customErrors mode="Off" defaultRedirect="/Errors" />
 

This will send any error to Event Viewer directly.

9.2. Only for Ornish: certificate configuration needed for API.

If the following URL does not open correctly in a browser:
 
http://diawebornish.healthways.com/api/v1/ornish/Referrals.svc
 
Check event viewer. The reason might be that DiaWEB is unable to locate the certificate indicated in the following setting in the Web.config file.
 
 
This is the setting by default (which most probably wont work in production):
 
<serviceCertificate findValue="localhost" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName" /> 
 
We might need to change the values for "findValue" and "storeName" as shown in the image below notes from Heather below, depending on the certificate; we have to use looking at the "certmgr.msc" app to find this info.
 
Notes from Heather:
  • The certificate will most likely be in the Personal folder rather than Trusted Root Certification
    • this is fine - it can stay there
  • Rather than using the Subject to identify the certificate, we had to get the Thumbprint, which is:
    • a hexadecimal value
    • no spaces between the characters
    • lower-case characters is  fine
    • Gotcha: if you copy from cert manager, a non-printable character may be included at the beginning, so you'll need to either manually re-type it or otherwise ensure that that invisible character isn't copied/pasted into the config file - otherwise it will not work but won't be apparent why
  • You'll have to change the X509FindType value to "FindByThumbprint"
<serviceCertificate findValue="Hexadecimal Thumbprint Value" storeLocation="LocalMachine" storeName="My" x509FindType="FindByThumbprint"/> 
 
 
 
 
 
 
Optionally, and only as temporary workaround, this setting could be removed or commented out like the following:
 
<!--serviceCertificate findValue="localhost" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName" /-->
 
If the applications connecting to the API aren't validating the certificate (wouldn't be rare), they should be able of continue using the API.
 
9.3. Only for Ornish, if API URLs are not working.
  • Check if binding for https is added to the site in IIS.
  • Check if any error with more details appears in Event Viewer in Windows.
  • Verify that we have all the required Windows features indicated in the section 3.
  • Verify that we don't have installed the "WebDAV Publishing" Windows feature.
  • Verify that we have a binding for https.
  • If more features are installed or uninstalled and any of the APIs continue not working it might be needed to remove the DiaWEB site from IIS and add a new one instead.

9.4 For API users, if behind a load balancer such as Netscalar, SSL/TLS must terminate in IIS on the actual web server rather than the load balancer.

Prior to this happening, we encountered issues with the SOAP version of the API in which we could view the .NET WCF:

Clicking on the link with '?wsdl' should then display the XML WSDL. However, prior to terminating SSL/TLS at the IIS server, the WSDL would not display - the user was left at the above screen. Trying to make a call to the API resulted in 404-Not Found.