Guides the user through the steps necessary to create an SQL server database and ICDS (Innova Central Database Server) web server via the Amazon Web Services (AWS) cloud-based platform.
The purpose of this document is to guide the user through the steps necessary to create an SQL server database and ICDS (Innova Central Database Server) web server via the Amazon Web Services (AWS) cloud-based platform. The system diagram below details how the SQL server database and ICDS Web Server fit in to the structure of data flow within Well Seeker Pro.
Before you start, to save time, there are some programs which should be downloaded and installed, as access to these will be required at various points throughout the document.
You will also require credit card details while setting up the AWS account, so have these to hand.
These programs and the relevant links are detailed below.
Download the 32-bit MSI.
During installation, select the Commander interface style.
Installation of SQL Management Studio can take a while, which is normal and expected.
In addition to installing the above programs on your computer, install the Google Authenticator App on a suitable mobile phone.
Throughout the setup process, the user will be required to enter numerous different login details and passwords. All of these will be unique to the user. The below table lists the various details the user will be required to supply, along with a blank cell, where they can keep track of these details during the process. It is recommended that this table is completed as the user follows the steps keeping all details in one place for easy reference during and after the setup has been completed.
1. Go to https://aws.amazon.com/
2. Click “Create an AWS account” in the top-right corner.
3. A suitable email address should be used, and the password should be very secure.
a. Note, it is necessary to add payment details to allow Amazon to verify your identity and if the “AWS Free Tier Limits” are exceeded your card will be charged.
b. You then need to confirm your identity via phone so are asked to enter your phone number for text or voice call verification.
4. The user then needs to select the relevant plan. Smaller companies can select the basic plan, while larger companies may prefer to select the Business Plan. For the purposes of this guide the Free - Basic Plan was selected. Once selected, the user will be taken to the below right page.
5. Once an AWS account has been created, the user can then sign into the AWS Management Console.
6. As this is the first time logging in, the user must select to sign in as a Root User. The Email address and Password required here are the ones entered while creating the AWS account.
7. Once the user has signed into the AWS Management Console, click on Services at the top left of the console and go to IAM (Under Security, Identity & Compliance).
8. Click on activate MFA on your root account.
a. This takes you to the below screen, where you select Multi-Factor authentication (MFA) and then Activate MFA.
9. With Virtual MFA device selected, click continue. You will see the below window.
10. Go to your phone and open the Google Authenticator App, which you should have already installed.
11. Click on show QR code and scan this with the app on your phone.
12. Enter the 1st MFA code, wait and enter the 2nd then click assign MFA.
a. The app keeps generating codes every 30 seconds. You need to enter 2 consecutive codes. If successful, you get the below.
b. Note, with this set up, every time you try to log into the AWS management console, you will need your password, and then it will ask you to enter the MFA code. You will therefore need to open this app again and enter the code which you see every time you log in.
13. Go back to the IAM dashboard. This option is available on the top left of the screen, just above access management.
The AWS website states the following:
“We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks.”
This section will guide the user through the steps required to set up an IAM user.
14. Click on create individual IAM users and select Manage Users. You will get the below.
15. Click Add User.
a. Enter a Username and access type.
i. Selected BOTH Programmatic Access and AWS Management Console Access.
b. With AWS Management console access selected you are then prompted for some password info. Select Custom Password, create a password and remove the Require Password reset option.
c. Take a note of your IAM Username and Password.
d. Select Next: Permissions.
16. Create a group
a. Group name must have no spaces. This opens the below right dialog.
b. Enter the Group Name and select the following policy:
i. AdministratorAccess
c. Select Create Group at the bottom right.
17. This then takes you to the below window. Make sure that the check box beside the group name is checked. Take a note of the Group Name. Select Next: Tags.
18. This then takes you to the below window. Select Next: Review.
19. This then takes you to the below window. Select Create User.
20. This then takes you to the below window. Select Close.
21. In the below, click on the username and this opens the User Summary.
a. Select the Security Credentials Tab and select Manage beside “Assigned MFA Device”.
22. Assign Virtual MFA Device. Do this for each user. This will open a similar screen like before, where you need to scan a code in the Google Authenticator App.
a. In the app, press the little white plus symbol and scan the barcode.
b. You will now have 2 sets of codes generating. One for the Root account and one for the User.
23. Once this is done, select Users at the top left of the window and you will see below where the MFA is showing as Virtual.
24. Go back to the IAM dashboard.
25. You now need to Create a password policy by selecting:
a. “Apply an IAM password policy” – “Manage Password Policy” – “Set password Policy”.
b. This is now the user’s choice, but as minimum it is suggested to select “Require at least one upper Case and one number, plus min 6 characters”.
c. Hit save changes.
26. With the above now in place, when logging into the AWS Management Console, if the user wishes to, they can select to sign in as an IAM User (instead of Root User). When selected, the user will be asked for the Account ID (12 digits) or Account Alias.
a. Enter the username and on the next page, the Account Id will be populated. Take a note of this.
b. Note: When prompted to enter the MFA code, remember to enter the code associated with the user account, and not the root account.
It is now time to create your database on the AWS. The following section will guide you through database creation steps and the relevant security rules which need to be added to allow the ICDS (Innova Central Database Server) to communicate with the database.
27. Click on Services and under Database select RDS (Relational Database Service).
28. Before you proceed, you must select the relevant region you want the Db to be created in. This option is available from the top right of the screen, to the right of your account details in the navigation bar.
29. Select - Create Database. Note, below the Create Database button, it will tell you where the Db instance will launch. Make sure this is as expected. If not, you may need to repeat the previous step.
30. Step 1: Create Database:
a. Choose Standard Create as the database creation method.
31. Step 2: Engine Options:
a. Choose Microsoft SQL server as the engine type and then SQL Server Express Edition for the edition. Notice that the express edition is eligible for the RDS free Usage tier.
b. Set the version to SQL Server 2017 14.00.3049.1.v1.
32. Step 3: Templates:
a. Select Dev/Test as the template.
33. Step 4: Settings:
a. Db Instance Identifier: Enter the name you want to use for your RDS database name.
b. Master Username: Enter a master username of your choice.
c. Master Password: Enter a master password of your choice.
d. Take a note of your chosen DB Instance Identifier, Username and Password.
34. Step 5: DB Instance Size:
a. Choose db.t2.medium (2 vCPU, 4 GiB RAM) as the DB instance class.
35. Step 6: Storage:
a. Storage Type: General Purpose (SSD).
b. Allocated Storage: 100 GiB.
c. Storage Autoscaling: Leave as the default, Enable storage autoscaling.
d. Maximum Storage Threshold: 1000 GiB.
36. Step 7: Connectivity:
a. Virtual private cloud (VPC): Choose the default VPC.
b. Click on Additional connectivity configuration to enable the following options:
c. Subnet Group: Choose the default subnet group.
d. Public Access: Choose Yes.
e. VPC Security Group: Select Create New and give it a suitable name such as “RDS Security Group.” Note - Once the DB Instance is launched you will have to wait 10-15 mins for the security group to be created.
f. Availability Zone: Choose No preference
g. Database port: Ensure that the port is changed from the default 1433 to 41433.
37. Step 7: Microsoft SQL Server Windows Authentication and Additional Configuration:
a. Leave Microsoft SQL Server Windows Authentication turned off.
b. Click on Additional Configuration to enable extra options.
38. Step 8: Database Options:
a. DB parameter group: Pick default.sqlserver-ex-14.0.
b. Option group: Pick default:sqlserver-ex-14-00.
c. Time zone: Choose your local time zone.
d. Collation: Leave blank.
39. Step 9: Backup:
a. Turn on Enable automatic backups.
b. Set the Backup retention period to 7 days.
c. Set the Backup window to No preference.
d. Turn off Copy tags to snapshots.
40. Step 10: Other Options:
a. Performance Insights: Turn off.
b. Monitoring: Turn off.
c. Log Exports: Turn off.
d. Maintenance: Turn on Enable auto minor version upgrade and set the Maintenance window to no preference.
e. Deletion protection: Turn on.
41. Select Create Database and you will get the below left screen. Below right is what you will see if you select “View DB Instance Details.”
a. Note: Depending on the region you have selected, the database can take a while to create. Sometimes over 30 mins.
42. Select Services – RDS.
43. Select Databases.
44. Click on the Db identifier for the Db that you are interested in.
45. At the top of the Connectivity and Security Tab, you will see the Endpoint and Port displayed. Take a note of these as they are required later in the setup process.
46. At the right-hand side of the Connectivity and Security Tab, you will see the VPC Security Group. Select this and then select the details tab.
a. Take a note of the Security Group Name and ID, as you will need to assign these when setting up the final security rules.
Now that the database has been created, the user must create some security rules, to allow communication between
The ICDS (located on the EC2 Instance) and the RDS database.
Well Seeker and the RDS database.
SQL Server Management Studio and the RDS database.
47. Select Services – RDS.
48. Select Databases.
49. Click on the Db identifier for the Db that you are interested in.
50. Scroll down till you see the security group rules section. There is an inbound and outbound and both need to be adjusted. This is so that there is no restriction to the computers which can connect i.e. any IP address can connect.
a. This is done so the user can test connectivity, but eventually, the IT department will need to put something in place here to make it more secure. Further details regarding this are provided in Section 15.
51. Select one of the security groups (inbound or Outbound) and the user will be taken to the below, which will open in a separate tab in the browser.
52. Select the inbound Rules Tab and edit the rules to mirror the below and select Save Rules.
a. 0.0.0.0/0 effectively means traffic from ALL IP addresses are allowed.
53. Now, select the outbound rules tab and edit this in the same way.
Now that the database has been created in AWS, the user needs to connect to it remotely, to finalise the setup. This involves using SSMS and Well Seeker Pro.
54. Open SQL Server Management studio.
a. Server Type: Database Engine.
b. Server Name: This is the Endpoint followed by a comma, followed by the Port number.
i. The Endpoint and the Port can be found in the AWS console by selecting Services – RDS and then selecting the database. It is displayed in the Connectivity and Security Tab.
c. The Login and Password for the database are the same as when the database was created in the AWS Console.
55. Right click on the databases folder and select create new database.
56. Give the database a name and select add then ok.
a. It is important to take a note of the database name, exactly as it has been entered, as this is case sensitive and will be required to access the Db via Well Seeker.
57. Once the Database has been created, close SSMS.
58. Open Well Seeker.
59. Go to File - SQL server databases - connect to remote database.
60. Enter the relevant information to connect:
a. Database IP/URL: Enter the Endpoint here.
b. Database Name: Database name as created in the previous section.
c. Port: 41433
d. DB Username: Master RDS Database Username.
e. DB Password: Master RDS Database Password.
f. WS Username: Master RDS Database Username (Must use this the first time).
g. WS Password: Master RDS Database Username (Must use this the first time).
61. Click connect
a. It is likely it will say the Db schema is out of date. Select yes to update.
b. It will say there are no admins and ask if you want to make this user an admin. Select yes.
62. On first connecting, Well Seeker will create all the relevant tables in the SQL database.
63. You can now close Well Seeker.
64. Open the server database in SQL Server management studio.
65. In the Object Explorer Tree, navigate to the tables folder under your database.
66. Scroll down till you get to the dbo.DB_SETTINGS table.
67. Right click on the table and select Edit Top 200 Rows.
68. Insert a single record in to the table: ./icdsFileDir/
a. This sets the field IMAGE_PATH for the remote Db, which is where any logos and attached files will be stored.
An EC2 instance is a virtual server in Amazon’s Elastic Compute Cloud (EC2) for running applications on the Amazon Web Services (AWS) infrastructure. AWS is a comprehensive, evolving cloud computing platform; EC2 is a service that allows business subscribers to run application programs in the computing environment. This is where the ICDS (Innova Central Database Server) will be installed.
69. Click on services and under Compute, select EC2.
70. IMPORTANT – You now need to select the region you want the instance to launch in. To do this, select the drop down in the toolbar at the top right of the screen. Select the closest region to your operations to reduce lag.
71. Click on Launch Instance – select the latest Ubuntu server – 64-bit (x86).
72. Select the Free Tier Eligible option shown below.
a. Select Review and Launch.
73. Select Edit security groups and change the name to something suitable e.g. “EC2 Security Group.”
74. Select Launch.
75. Select to Create a new key pair and enter a key pair name.
76. Download the Key Pair. This will be a .PEM file.
b. Keep this file in a safe place as it is VERY IMPORTANT.
77. Once downloaded, select Launch Instances.
78. You will now get the below.
c. An optional step here is to set up the Billing alerts to warn when the usage is approaching or exceeding the free tier.
d. Select View Instances.
Now that the EC2 instance has been created, the user must create some security rules, to allow communication between:
The ICDS (located on the EC2 Instance) and WS (data fetch and exchange).
The ICDS (located on the EC2 Instance) and the RDS database.
The EC2 and the admin’s PCs, for use of WinSCP and PuTTY software.
79. In the AWS Console, select Services – EC2.
80. Select Running Instances and select the instance that you just created.
81. Take note of the EC2 Public IPv4 Address.
82. Select the Security Tab and select the security group.
83. Take a note of the Security Group Name and ID, which can be found at the top of the screen, as you will need to assign these when setting up the final security rules.
84. Select Inbound Rules and select to Edit inbound rules. There will already be an SSH rule for port 22. Add a new rule as below, where All traffic is allowed. Select Save Rules.
a. This is done so the user can test connectivity, but the clients IT will need to put something in place here to make it more secure. Further details regarding this are provided in Section 15.
85. Open puTTYgen.
86. Select load and select the PEM file (you will have to change the file type filter to all files (*.*)
87. Click OK to the notice.
88. Click save private key, it is ok not to use a passphrase. Again, keep this file in a safe place as it is very important.
89. Close puTTYgen.
90. Open win SCP.
91. Select protocol as SFTP.
92. Enter the EC2 ipv4 address in the hostname.
93. Username is ubuntu
94. Password is blank
95. Port is 22
96. Click on advanced -> SSH -> Authentication and select the browse option to the right of the private key input cell and select the private key that was created with puTTY gen. Select OK.
97. Click login and click yes to the security notice.
98. You will now have the below, where you have created a drag and drop file explorer interface to the AWS EC2. If you do not see the Ubuntu folder on the right, its likely because you are already in it. Just select the only folder showing and it should then display the ubuntu folder.
99. Download the ICDS files via the link provided by Innova.
100. Remove the .linux extension from the icdsServer.linux file.
101. Drag this Linux executable icdsServer file to the ubuntu EC2 folder below right.
102. You will get the below left popup. Select OK and you get the below right.
103. Open the attached configICDS.json in a text editor e.g. Notepad
a) CompanyID: Type Company Name (this will be supplied by Innova and must be written in EXACTLY the same way as its supplied). Make sure Company Name is inside double quotes
b) Port: Usually enter the port field as 42000 (no quotes) – this is the port which will be entered into the Well Seeker RT Data exchange for communication with the ICDS
c) devmode: Leave as false (no quotes)
d) sqluser: Set to the SQL Server master username used to access the database. Make sure this is inside double quotes
e) sqlpass: Set to the SQL Server master password used to access the database. Make sure this is inside double quotes
f) sqlsvr: Set to the SQL Server RDS database Endpoint. Make sure this is inside double quotes.
g) sqldbname: Set to the name of the database you wish the ICDS to connect to. This is the database name that you see when logged in to SQL server Management Studio. Make sure this is inside double quotes
h) sqlport: Set to the port used to connect to the SQL server database (no quotes), usually this is 41433
i) externalPath: Specifies where external files are stored. Input either useDatabase (stores files on the EC2) or useS3 (stores files on an S3)
j) sqldbnamewits: If a user is pushing and storing WITs data to a database separate to the Well Seeker database, insert the name of the database here. Make sure this is inside double quotes. If this function is not used then leave a the doubles quotes empty
k) transferWits: If pushing WITs data to a second database then enter true, if not enter false
l) allowActivePush: If true is entered then a computer can push data back to a server database regardless of the well status. If false is entered then a computer can push data back to a server database only when the well status is Upcoming, Active or Standby. The well status is selected in the Daily Reports dialog
m) awsAccessKeyID: If storing external files on an s3, input the AWS Access Key ID of the IAM user. If not leave blank
n) awsSecretKey: : If storing external files on an s3, input the AWS secret key for the IAM user. If not leave blank
o) awsRegion: : If storing external files on an s3, input the region where the AWS service is hosted eg “us-east-2” or “us-west-2”. If not leave blank
p) s3Bucket: If storing external files on an s3, input the name of the S3 bucket which was created to store the Well Seeker external files. If not leave blank
q) Leave all other fields as they are
104. Once completed, drag the config.JSON file to the same directory as the icdsServer file
105. In the same sub directory as the icdsServer executable is located, create a directory called icdsFileDir.
a. To do this, right click under the icdsServer file and select New – Directory.
b. Your folder should now look like the below
c. This folder is where the logos and external files added to the remote database will be saved.
106. Close WinSCP. You will get the below. Selected No, so that the workspace is saved.
107. Open PuTTY
108. In the Host Name Cell: Type ubuntu@ then the EC2 ipv4 public IP we took note of earlier. Add this information to the login details section of this document.
a. Select the port as 22 and name the session in the saved sessions box.
109. Then click on Connection - SSH – Auth.
110. Click Browse and select the ppk file created earlier.
111. Click open.
112. Click Yes to the security alert message. You then get the below.
113. Follow the instructions on the following link to install node on the EC2 instance: https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/setting-up-node-on-ec2-instance.html
a. There are a set of commands which need to be entered into Putty. At the end of each line there is a copy button which copies the code. If you then right click on the bottom line in the putty interface, it pastes the code in for you.
b. Hit enter and then move onto the next code.
c. Your putty interface should look like the below right by the end.
114. Enter the following into the command line to install PM2: npm install pm2 -g
d. You should get the below after entering this.
e. PM2 is just a program which allows you to run a file as a service i.e. if it crashes or the computer restarts it will restart the program automatically.
115. Check pm2 is running by typing pm2 ls
f. You should get below after entering this.
116. Update node. Type the following command: nvm install 4.4.5 check version number from node.js website
c. You should get the below after entering this.
d. Node.js is a java script library for linux which is required to run the program PM2.
117. Type: sudo apt-get update
a. You should get the below after entering this.
b. At this point close and reopen putty. If you do not do this, when you get to the point where you type a pm2 command, putty will tell you it is not recognised. Not sure why this happens, but it is a consistent error. Closing and reopening puTTY allows you to proceed without any issues.
118. You now need to change the file permissions using the following “Change Mode” command: chmod 777 icdsServer
b. This makes the file readable, writable, and executable by everyone.
c. If you do not do this step, then in the next step you will likely get an errored message like the one below.
119. Now setup default instance using config file: pm2 start icdsServer
d. You should get the below.
e. Note that the “icdsServer” is the name of the linux file which was placed in the EC2 instance via WinSPC. If you have changed the name for any reason, then you will need to adjust the command by replacing “icdsServer” with whatever the name of the file you added is.
120. Enter pm2 ls again. You should see the icdsServer status as online still. If the status is errored then something is wrong with the setup
121. Save the current pm2 settings so it starts correctly after a server restart: pm2 save
The following is a list of useful commands which can be used in puTTY and relate to pm2. These may be helpful if there are any issues / errors when starting the pm2 application.
122. Stop any current pm2 icds processes: pm2 stop icdsServer
123. Delete old pm2 config params: pm2 delete icdsServer
124. Kill any pm2 process which is running: pm2 kill
125. View list of pm2 running apps: pm2 ls
126. View logs: pm2 logs
Well permissions have been put in place to give the admin control over what computers can pull what wells via the remote data fetch functionality from the SQL server database, if required. This might be the case when a company employs consultant rig personnel, who they do not want to have access to their historical well data. In order to access and setup well permissions follow the below steps:
127. Log on to the SQL server database via Well Seeker Pro
128. Once connected, select Tools > Well Permissions. This will open the Well Permissions dialog. Note that only Well Seeker users with Admin permissions can access the Well Permissions dialog
129. Well Permissions can be set to two states:
a. Enable Individual Well Permissions disabled. To select this option uncheck the Enable Individual Well Permissions check box. This allows any company computer with Well Seeker installed on and a user who has the EC2 IP address and port number details to pull any and all well data from the SQL server database via the Remote Data Fetch dialog
b. Enable Individual Well Permissions enabled. To select this option check the Enable Individual Well Permissions check box. When this is selected no computers are able to pull down well data via the Remote Data Fetch dialog, even if the user has a company computer with Well Seeker installed and the user has the EC2 IP address and port number details. Only computers entered in the table will be able to pull down a specified well or job number, when the active check box is selected.
The Computer Name for a computer can be found by right clicking on This PC and selecting Properties. Depending on the windows version the user has, the computer name will come under one of a number of different titles. These details will need to be updated on a well by well basis in order to allow the rig personnel access to the required wells
With the ICDS server now running it is important to test if this is working correctly. This can be done as follows:
130. Open the RT data exchange in WS and push an operator to the remote Db.
131. Create a new Db and then do a remote data fetch to pull in the well you have just added to the remote Db.
132. Open the RT data exchange and connect to the well you have added on the remote Db. Add some new data to the local Db and ensure that it pulls into the remote Db correctly.
133. Add a new plan to the remote Db and check to see if you receive the relevant notification in the messages window.
134. Add a couple of logos and external files to the remote database to ensure that these save correctly.
a. NOTE: For the logos and external files to work correctly, the user must have the Push External Files option selected in Well Seeker
Now that everything has been setup and tested, the final step is to adjust the security rules to make them more secure. If there is an issue connecting after this stage, you can then be sure that the issue is related to the setup of these rules and not any of the other previous steps.
Below are some recommended settings. The RDS database has communications with:
The ICDS (located on the EC2 Instance).
Well Seeker / SQL Server Management Studio.
When creating a security rule, the 2 main pieces of information required are the Port and the IP address. Set the RDS Incoming and Outgoing Security rules as detailed below:
1. Rule one:
a. Type: Custom TCP
b. Port: 41433
c. All public IP addresses that require access to the RDS via either Well Seeker or SQL Server Management Studio.
i. For larger companies who have the relevant IT structure, they may want to set an IP range for computers in their network. This is more secure.
ii. If there are just a few IP addresses to be added, the smaller companies can find each Public IP by accessing the web browser on each computer and typing “ip4.me” into the address bar at the top of the page.
iii. If a company does select an IP range, and we end up having to provide support, they may need to add our IP addresses in as a rule otherwise we will not be able to access.
iv. End the IP addresses with /32.
2. Rule Two:
a. Type: Custom TCP
b. Port: 41433
c. Security group assigned to the EC2 instance.
The EC2 instance has inbound communications from:
WS - data fetch and exchange.
RDS database.
WinSCP and PuTTY
When creating a security rule, the 2 main pieces of information required are the Port and the IP address. Set the EC2 Incoming and Outgoing Security rules as displayed below:
1. Rule One (This should already be present when you open the rules dialog):
a. Type: SSH
b. Port: 22
c. Only public IP addresses of admins who will be using WinSCP or Putty to access the EC2.
2. Rule Two:
a. Type: Custom TCP
b. Port: 42000
c. All public IP addresses to be allowed.
i. The reason to allow all public IP addresses is because it is difficult to know the relevant public IP addresses for each rig computer which is out with the company’s network. Setting a range here could mean some rig computers are unable to communicate with the ICDS.
ii. For larger companies who have the relevant IT structure, they may want to set an IP range for computers in their network. This is more secure.
iii. If a company does select an IP range, and we end up having to provide support, they may need to add our IP addresses in as a rule otherwise we will not be able to access.
3. Rule Three:
a. Type: Custom TCP
b. Port: 41433
c. Select the security group assigned to the RDS.
There may be times when a user is experiencing issues with logging in to the SQL server database via SSMS or Well Seeker, or where the external files / data push and pull functions are not working. The below sections will guide the user through some problem solving steps that will help isolate and solve the issue in question.
If the user receives an error message and cannot log in to the RDS via SSMS then follow the below steps:
1. Check the user’s computer has internet connectivity
2. Check the Server type is Database Engine
3. Check the Server name is the RDS endpoint, immediately followed by a comma, then a space and then the RDS port number, which is usually 41433. For example:
a. RDS Endpoint = exampleendpoint
b. RDS Port = 41433
c. Server name entered = exampleendpoint, 41433
4. Check the authentication type is SQL Server Authentication
5. Check the Login entered is the RDS Username the user created when setting up the RDS
6. Check the Password is the RDS password the user created when setting up the RDS
7. If the above checks still haven’t fixed the problem the remaining potential cause is the RDS security settings. Log on to the AWS account, select the RDS in question and review the security settings. See section 16.1 RDS for more details.
Note that if individual IP addresses have been specified in the security rules, it is not uncommon for a network router provided by a third party to change a computers public IP address. To see a computers public IP go to ip4.me in your web browser
If the user receives an error message and cannot log in to the SQL server database via Well Seeker Pro then follow the below steps:
1. Check the user’s computer has internet connectivity
2. Check the Database IP / URL is the RDS endpoint
3. Check the Database Name is the name of the SQL server database as it appears when viewed in SSMS. This should not be confused with the name of the RDS when viewed in the AWS account
4. Check the Port is the port number of the RDS, usually 41433
5. Check the DB Username is the RDS Username the user created when setting up the RDS. If the user has since created an additional user in SSMS, this user name can also be used, as long as they have the clearance to access the database entered in Database Name cell
6. Check the DB Password is the RDS password the user created when setting up the RDS. If the user has since created an additional user in SSMS, this user password can also be used, as long as they have the clearance to access the database entered in Database Name cell
7. Check the WS Username is correct. Each WS username has been created in the User Permissions dialog by a user with administrator permissions.
If the administrator cannot log on to the SQL server database via Well Seeker then they can log on to the RDS via SSMS and look in the dbo.USER_PERMISSIONS table to see if the WS username exists
8. Check the WS Password is correct. If the user has forgotten their password then the admin can delete the users password from the User Permissions dialog. The next time the user logs in they will be asked to enter a new password
9. If the above checks still haven’t fixed the problem the remaining potential cause is the RDS security settings. Log on to the AWS account, select the RDS in question and review the security settings. See section 16.1 RDS for more details.
Note that if individual IP addresses have been specified in the security rules, it is not uncommon for a network router provided by a third party to change a computers public IP address. To see a computers public IP go to ip4.me in your web browser
The Real Time Data Exchange is design to give a user the ability to push data for a specific well from their Well Seeker database, back to the SQL server database. The Remote Data Fetch is designed to give a user the ability to pull data for specific wells from the SQL server database to their Well Seeker database. In order to achieve this there are many things that have to be set up correctly
For both the Real Time Data Exchange and the Remote Data Fetch:
Correct IP and port number input in Data Exchange / Data Fetch dialog. These are the IP of the EC2 and the port number specified in the .json file on the EC2
Correct credentials entered in the .json file on the EC2. See 12.1 – ICDS files, step 103 for details
The ICDS server has to be running without error on the EC2. See 13.0 – PuTTY for details
The EC2 security settings have to be correct within the AWS account. See 16.2 EC2 for details
The RDS security settings have to be correct within the AWS account. See 16.1 RDS for details
For the Real Time Data Exchange only:
Correct well selected in the Data Exchange dialog. This well must already exist on the server data base
If the .json file on the EC2 has allowActivePush as false then a computer can push data back to a server database regardless of the well status. If true is entered then a computer can push data back to a server database only when the well status is Upcoming, Active or Standby. The well status is selected in the Daily Reports dialog. See 12.1 – ICDS files, step 103 for details
For the Remote Data Fetch only:
If the Well Permissions dialog on the SQL server database has Enable Individual Well Permissions selected, then only wells included in the Well Permissions table will be able to fetch specific wells. In the case that the user does not have permission to download well data, the user will be able to connect to the SQL server database and see the database tree, but there will be no structures below facility level to select, as below.
See 14.0 – Well Permissions for details
External files for the SQL server database are stored on the EC2 and rely upon a similar data transmission method as the real time data exchange and remote data fetch functions. If you are experiencing issues saving or accessing external files and logos, either from the SQL server database, or when the data has been pulled down to a local database, follow the below steps:
1. Ensure the real time data exchange and remote data fetch functions are working correctly. See 16.3 – Real Time Data Exchange / Remote Data Fetch for details. If they are then it rules out a number of potential causes for the issue. If both these functions are working, but you are still experiencing issues with the external files functions then proceed to the next step
2. Ensure that during the database creation the step was followed that created the external files image path in the dbo.DB_SETTINGS table. See 14.0 – Well Permissions, step 68 for details
3. Ensure that the option Push External Files is selected on all computers trying to use the functionality
