4A. ENOWA-SGIS-WPS (Primary GIS Server)
This page details the configuration of the Primary GIS Server, ENOWA-SGIS-WPS, and outlines the setup process.
Hostname
ENOWA-SGIS-WPS
FQDN
ENOWA-SGIS-WPS.neom.local
IP Address
10.135.46.4
Location
NourNet (KSA)
CPU (Chip)
2.1 GHz Intel Family 6, Model 45 (2D)
CPU (Core Count)
8
RAM
32 GB
C: Space
200 GB
D: Storage
500 GB
Network
neom.local
Gateway: 10.135.46.1
Subnet
255.255.255.224
Bandwidth
4 Gb/s
Operating System
Windows Server 2022
Environment
Sandbox
Role
Primary Enterprise GIS Server
Software(s)
Portal for ArcGIS, ArcGIS Server (Hosting), GeoEvent, Web Adaptor(s), ArcGIS License Manager, ArcGIS Pro
All version 11.0
Proxy URI
Alias(es)
The above photo is a screenshot of the BGInfo desktop. You can see the machine details by using this reference, or by navigating to the machine's Control Panel (Settings), or by using the command line tools described earlier in the document.
Service Accounts
All Windows services are run by an account, which informs the application's permissions, capabilities, and access rights. The service account being used by the system is: NEOM\enowagisrv
u: NEOM\enowagisrv
p: N#0MenOw@2)3(
This account is used to run the Windows Services corresponding to the ArcGIS component. This account is known as the Service Account. The Service Account is different than application/user accounts and does not correspond to a user within the Portal (or whichever ArcGIS component is being targetted).For instance, the Portal for ArcGIS application installs and runs a service called 'Portal for ArcGIS' on the target machine.
From a practical perspective, this means that when an ArcGIS Service (Portal for ArcGIS, ArcGIS Server, ArcGIS Data Store, etc.) tries to communicate with another machine, connect to a database, or attempt to access files, the activity will be completed by the service as the NEOM/enowagisrv user. So, in order for the system to work properly, this service account must be granted the appropriate permissions, access rights, and be taken into account when considering workflows and integrations.
Granting Permissions to Service Account
To ensure this account has the necessary permissions to complete the work, we are going to add the Service Account user, NEOM/enowagisrv, to the Local Administrators group of the ArcGIS Enterprise machines. This ensures that the Service Account will have the necessary permissions to install the software, to access the required directories, and is able to operate without hindrance.
There are many ways to add this user to the Local Administrators group, but the simplest is to leverage the Control Panel's 'Edit local users and groups' dialogue. Once opened, expand 'Groups' and double-click the 'Administrators' group. Use the dialogue to search for the NEOM/enowagisrv account and add this user to the group.
Once added, our service account should have the necessary local permissions to install and run the software.
Note: when searching for Windows (domain) users, be sure to change the scope of the Windows Search to 'All Directories' soasto ensure the search is executed against the domain and not just local user profiles.
Create Working Directory for Resoures
We created a directory on the D: drive called 'arcgis' which will house the ArcGIS Enterprise content, data, and server directories. We separate these 'operational files' from the application files as these resources have high i/o, can often grow/swell to large sizes, and to offer more resillience in the event of drive failure. Additionally, as the D: drive doesn't run the OS, we can more easily expand the D: drive if necessary, whereas expanding the C: drive is often not possible/not feasible/not easy.
Install directory: D:\arcgis
Enabling Database Connectivity
The ArcGIS Enterprise system leverages a SQL 2022 Enterprise Geodatabase. In order for the machines participating in the deployment to communicate with the SQL Server Database, special drivers must be installed to allow for ODBC (Open Database Connectivity) communication between the application servers and the database server.
We installed the ODBC_18.1 for SQL 2022 support. This will allow for ArcGIS Pro, Portal for ArcGIS and the ArcGIS Server(s) to communicate with the Enterprise Geodatabase.
Enabling Internet Information Services (IIS)
Since this machine will also be running the Web Adaptor(s), which are load-balancing, reverse proxy web applications, this machine requires Windows' Web Server component, IIS (Internet Information Services (noone calls it this)). This can be enabled through the 'Turn Windows features on or off' dialogue through command line. Alternatively, this component does not need to be setup prior to any component installation as the Web Adaptor installation process will enable this Windows feature if it is not already enabled.
Once enabled, you can launch IIS to view your web server's management console. By default, IIS only supports HTTP (unencrypted) communication.
Reminder: computer communication always happens over a specific channel (port). HTTP traffic is universally set over port 80 over the internet. Remote Desktop Connections (RDCs) operate on port 3389 by default. SQL Server communication happens over port 1433 by default. And HTTPS communication happens over port 443 on the internet.
Binding Port 443 (Enabling HTTPS)
To enable HTTPS communication on the web server, we must bind HTTPS to port 443. Again, by default, port 80 is already bound to HTTP traffic, thereby enabling it. So, said differently, binding port 443 to HTTPS enables HTTPS communication on the web server.
You bind HTTPS to port 443 by clicking on the dropdown for your 'Default Web Site.' Once selected, the main operating frame will update with the appropriate items and the right-docked panel will likewise update.
On this right-docked panel there is a heading for 'Actions' and under the 'Edit Site' sub-heading there is a button labeled 'Bindings...'. Click on this button, which will open the 'Edit Bindings' dialogue. Hereon, change HTTP to HTTPS and select the default certificate. Do not change/specify the hostname and do not update the default port number. Click apply.
Generating Trusted CA-Signed Certificate (SSL)
Now our web server supports both HTTP and HTTPS traffic. However, the HTTPS traffic will throw errors as the certificate we chose was self-signed, meaning that only the local machine trusts/recognizes the certificate. To address this issue, we are going to request a domain certificate from the organization's internal Certificate Authority (CA). The CA is an entity which manages trust through certificates and keys. In layman's terms, there are two (2) types of CAs:
External Certificate Authorities
Internal/Domain Certificate Authorities
External CAs, such as GoDaddy, DigiCert, Verisign, exist as a globally recognized and trusted authority for the provisioning and management of strong, reliable, and accountable certificates. For public websites, a public certificate is required to support HTTPS traffic.
Internal CAs provide the same functionality as external CAs, except that they are scoped differently. Rather than being trusted by everyone, Internal CAs are only trusted by the machines/components/servers that are within the scope of the CA. For instance, the ENOWA's sandbox environment has an internal CA, which allows us to create trusted certificates within the neom.local domain. The CAs are managed by the organization's DNS/AD team and are trusted by resources through group policy.
Note: Certificates provisioned through external CAs are trusted both internally and externally. So, if an organization does not have an internal CA, they may provision a certificate from an external CA which will allow their site to be trusted by all internal parties.
To request a certificate, you could use IIS, however the tooling therein is limited and you cannot fully configure your certificate. To allow for more control into the certificate creation process, we will instead by relying on Microsoft's Management Console (mmc). To launch mmc, type 'mmc' into the Windows Search and select the resulting command.
Once opened, click on 'File' from the main navigation and select the dropdown option for 'Add/Remove Snap-in...'. This will open the Snap-In GUI.
On the GUI, select the option for 'Certificates' and select 'Add', which will open a secondary interface for us to configure the certificate. Once loaded, we will immediately update the radio input to have 'Computer Account' selected. This will ensure the certificate we are requesting will be all by associating the certificate with the infrastructure rather than a user profile. Click 'Next'
The next screen will ask if this if for the Local Computer or another computer. By default, Local Computer is selected and that is the one we want, so you can click Next/Finish. Once added, you'll return to mmc and see the Certificates Span-In on the left-docked panel.
From here, we will navigate into the 'Personal' sub-directory. This is where our functional certificates will live. Do not overthink the term 'Personal' as this is not specifically "yours," but is an artifact from previous Windows iterations of the Certificate Authority. Ultimately we are interested in creating a password-protected .pfx Web Server certificate with its private key exportable.
From the main panel, right-click into white space, hover over the 'All Tasks' dropdown and select the option to 'Request New Certificate.' This will lanuch a certificate request GUI. You can click 'Next' on the first two screens which generally never need to be changed unless an organization has a non-domain managed CA, which I have seen exactly zero times :)
On the third screen you'll be asked to choose what certificate template you are interested in. Scroll to the bottom and select 'Web Server.' Once selected, you'll notice that you cannot click the 'Enroll' button yet to move forward. That is because we must provide information within the selected template. To do so, click on the blue hypertext that appears directly below the Web Server item.
We then created a certificate called 'GIS Web Certificate.'
Applying CA-Signed Certificate to IIS (443 Binding)
And now that we have a trusted certificate, we can go back and update our bindings within IIS to use this certificate instead of the self-signed one we set earlier.
At this point, we will reboot the machine to force any reboot-locked changes and/or cached states to be recognized and updated.
Last updated