Table of Contents |
---|
Luma Automation has the ability to define, build, orchestrate and manage workflows that support system and network operational processes. The Automation Workflow Services can integrate with remote services, servers, applications, and hardware to perform tasks. The orchestration process can cross all management disciplines and interact with all types of infrastructure elements, such as applications, databases, and hardware.
To facilitate automation on systems that are available on the Customer network and cannot be accessed outside the network, Luma Serviceaide Automation supports a hybrid implementation:
SaaS Implementation:
...
Serviceaide Automation cloud instance is implemented on Serviceiaide infrastructure and is maintained by the Serviceaide Support Team. The System Administrator can build and design Workflow services to connect to remote services and systems that can be accessed over the internet.
On-Premise Agent Implementation: The Automation Orchestrator component is deployed on the Customer’s local infrastructure within the customer network or private cloud. The Orchestrator allows integration with services that cannot be accessed outside the customer network, such as Active Directory (AD), and On-premise servers.
Info |
---|
From Release 2.0, the Automation Orchestrator is available as a SaaS implementation. The Orchestrator Engine will now be used to execute the discrete MuleSoft Operations through the Mule runtime. In addition to the Mule operations, it will continue to support the Legacy Mule Workflows (Legacy Connectors). |
...
Below the On-Premise Agent deployment Architecture for Luma automationServiceaide Automation. The Orchestrator component deployed in customer network polls the Cloud instance over HTTPS/443 port for secure and encrypted communication. An outbound connection is only required to be open from the customer network. No inbound rules/ports are required.
...
Integration with Active Directory
Serviceaide’s Luma Serviceaide Automation can be directly configured to reach out to AD Server if port 389 is open and available over the internet. If port 389 is not available over the internet and can be made only local, the automation orchestrator server is deployed on-premise which can connect to the local AD server on port 389. Luma Serviceaide Automation cloud instance connects to the Automation Orchestrator server over the internet.
...
Follow the below steps to Configure WINRM to use HTTP:
Run the following command to set the default WinRM configuration values.
c:\> winrm quickconfig(Optional) Run the following command to check whether a listener is running, and verify the default ports.
c:\> winrm e winrm/config/listenerEnable basic authentication on the WinRM service.
Run the following command to check whether basic authentication is allowed.
c:\> winrm get winrm/configRun the following command to enable basic authentication.
c:\> winrm set winrm/config/service/auth @{Basic="true"}Run the following command to allow transfer of unencrypted data on the WinRM service.
c:\> winrm set winrm/config/service @{AllowUnencrypted="true"}
Enable basic authentication on the WinRM client.
Run the following command to check whether basic authentication is allowed.
c:\> winrm get winrm/configRun the following command to enable basic authentication.
c:\> winrm set winrm/config/client/auth @{Basic="true"}
Run the following command to allow the transfer of unencrypted data on the WinRM client.
c:\> winrm set winrm/config/client @{AllowUnencrypted="true"}If the WinRM host machine is in an external domain, run the following command to specify the trusted hosts.
c:\> winrm set winrm/config/client @{TrustedHosts="host1, host2, host3"}Run the following command to test the connection to the WinRM service.
c:\> winrm identify -r:http://winrm_server:5985 -auth:basic -u:user_name -p:password -encoding:utf-8
Configure WinRM to Use HTTPS
...
Follow the below steps to Configure WINRM to use HTTPS:
Generate a self-signed certificate. The following command line contains example syntax for creating a certificate on the WinRM host by using makecert.exe.
makecert.exe -r -pe -n "CN=host_name-3,O=organization_name" -e mm/dd/yyyy -eku 1.3.6.1.5.5.7.3.1 -ss my -sr
localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 certificate_name.cerAdd the generated certificate by using the Microsoft Management Console.
Run mmc.exe.
Select File > Add/Remove Snap-in.
From the list of available snap-ins, select Certificates and click Add.
Select the Computer account and click Next.
Click Finish.
Verify that the certificate is installed in Console Root > Certificates (Local Computer) > Personal > Certificates and Console Root > Certificates (Local Computer) > Trusted Root Certification Authorities > Certificates.
If the certificate is not installed in the Trusted Root Certification Authorities and Personal folders, you must install it manually.
Create an HTTPS listener by using the correct thumbprint and hostname. The following command line contains example syntax for creating an HTTPS listener.
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="host_name";CertificateThumbprint="certificate_thumbprint"}Test the connection. The following command line contains example syntax for testing the connection.
winrs -r:https://host_name:port_number -u:user_name -p:password hostname"
Info |
---|
You may contact the Serviceaide support team for any assistance on On-Premise Agent implementation. Refer to ESA On-premise Agent v2.0 Runbook to follow the deployment steps. |
...