| Oracle® Enterprise Manager Application Configuration Console Installation Guide Release 5.3.2 Part Number E14652-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Enterprise Manager Application Configuration Console Installation Guide Release 5.3.2 Part Number E14652-02 |
|
|
PDF · Mobi · ePub |
The Windows Resource Extensions (WRE) is an Application Configuration Console product add-in that enables you to extract Windows configuration data from Windows servers to create assets in Application Configuration Console. To do this, the Application Configuration Console Server connects to a proxy service, which in turn, runs Visual Basic scripts on target machines to extract the data and pass it back through the Core Server to Clients. Figure 8-1 depicts the flow of information in a typical configuration.
From a Client, a user requests an asset load of a Windows asset.
The Core Server connects to the proxy service host, passing the relevant request information.
The proxy service executes the appropriate script on the target machine to extract the data and return it to the Client through the Core Server.
If you have purchased this product, your Application Configuration Console software distribution disc includes a Windows Resource Extensions folder with the following contents:
windowsre_wmi_scripts.zip–this zip file to extract the WRE scripts to the machine hosting the Application Configuration Console Proxy Service.
WindowsRE.jar–Use this JAR file to install the WRE automation module on Application Configuration Console.
Before you proceed with the installation, ensure that the respective environments satisfy the stated requirements.
General requirements include the following:
OpenSSH must be installed on the proxy host. See Section 8.3.1, "Download and Install OpenSSH."
The host machine operating system must be Windows 2000, Windows XP, or Windows Server 2003.
The credentials used to access the proxy service host and the target machines must be part of the Local Administrators Group on the machine. These credentials must have rights to execute the scripts on the proxy service host and to perform administrative tasks on the target machines.
Additional requirements depend on the Windows asset type.
The IIS 5.0 scripts use the ADSI provider to access configuration data. This requires that the IIS common files be installed on the proxy service host. If not already present, you can install them by opening Add or Remove Programs in the Control Panel and selecting Internet Information Services (IIS) > Common Files. Note that some of the scripts require that the proxy service be able to communicate with the target machines using UNC path specifications over TCP port 135 (RPC).
The SQL Server 2000 scripts use SQL-DMO to access configuration data. This requires that SQL Client Tools be installed on the proxy service host, specifically, the following selections:
"Client Connectivity
"Development Tools
"Header and Libraries
As SQL-DMO uses the Microsoft SQL Server ODBC driver to connect to and communicate with SQL Server instances, the proxy service must be able to communicate with the target machines using ODBC.
If there's a firewall in play, where you install the Application Configuration Console Proxy Service is a matter of resources and network conventions established at your site. Consider the following possibilities:
You can install the proxy service outside the firewall, as follows:
On the same host as the Core Server (option 1)
On a separate host from the Core Server (option 2)
"On a separate host from the Core Server and deployed in its own DMZ, the so-called demilitarized or demarcation zone (option 3)
You can install the proxy service inside the firewall, as follows:
On a host where a network server also resides (option 1)
On a host separate from the servers in your network (option 2)
Figure 8-2 illustrates the three possibilities identified when the proxy service is outside the firewall.
The proxy service uses WMI, SMB, and third-party COM APIs to extract information from target machines. These Windows technologies must therefore be accessible on the target machines. These technologies in turn use DCOM, which allocates random ports to communicate across the network.
Since the proxy service is outside the firewall, the firewall rules must allow communication between target machines and the machine hosting the proxy service on any TCP port over 1024 and on TCP port 135. The rules will need to allow the Windows file sharing ports as well. When the proxy service is in its own DMZ, the rules must be extended to allow communication between the Core Server and proxy service hosts using SSH over TCP port 22. Implicit in the first two options is that the Core Server uses SSH to communicate with the proxy service over TCP port 22.
Figure 8-3 illustrates the two possibilities identified when the proxy service is inside the firewall.
The proxy service uses WMI, SMB, and third-party COM APIs to extract information from target machines. These Windows technologies must therefore be accessible on the target machines. Since the proxy service is inside the firewall, the firewall rules must allow communication between the Core Server and proxy service hosts using SSH over TCP port 22.
The Application Configuration Console Proxy Service consists of the following components:
A version of OpenSSH to enable secure communication with the target machines
A set of Visual Basic scripts designed to extract configuration and other data from Windows servers
Note:
OpenSSH must already be installed on the machine hosting the proxy service. Additionally, there can be no Cygwin component on this machine.Use the following instructions to ensure that your OpenSSH setup conforms to the proxy service requirements:
Paste the following URL into your browser:
http://sshwindows.sourceforge.net/download/
On the page that opens, click Binary Installer Releases.
On the next page, download setupssh381-20040709.zip to the proxy service host.
Log in to the proxy service host as someone with administrative privileges.
Extract the zip file to a temporary directory.
Navigate to the directory where you extracted the zip file and run setup.exe. Proceed with the installation.
At Choose Components, select Server and Start Menu Shortcuts. Continue with the installation.
At Choose Install Location, enter the following as the Destination Folder:
C:\Program Files\OpenSSH
Continue with the installation.
A warning about editing the passwd file appears; this is addressed later in the chapter. Click OK.
When the installation completes, click Finish.
The scripts that ship with WRE must be installed in a fixed location so the resource specifications installed with the WRE Automation Module will work out-of-the-box.
To load the WRE scripts on the proxy service host:
Log in as someone with administrative privileges.
Create the directory mValentScripts under the OpenSSH installation directory, as follows:
C:\Program Files\OpenSSH\mValentScripts
Load the Application Configuration Console software distribution disc and navigate to the Windows Resource Extensions folder.
Extract the windowsre_wmi_scripts.zip file to the directory you created in Step 2.
Note:
If for some reason your organization does not permit use of OpenSSH and you have to use some other means of secure network connectivity, the
mValentScripts directory containing the scripts must be at root for WRE to work out of the box. So, for example, if you log in remotely, type cd /mValentScripts, and successfully change to that directory, you are properly configured. If you have questions or concerns, contact Support.You need a passwd file on the proxy host machine to be able to log in to and use SSH. The passwd file is the equivalent of the /etc/passwd file on UNIX-based systems. Application Configuration Console supplies a script to automatically create passwd and group files of all users and groups. The script gives you the option to create these files for either local or domain (or both) user accounts.
Local means only users with accounts on the proxy service host will be able to log in to SSH.
Domain means users in the domain will be able to log in to SSH, but local users will not be able to.
Both means that domain and local users will be able to log in to SSH. In case of duplicates, the domain user takes precedence; that is, the password associated with the domain user is required to log in.
To run the script:
Log in as someone with administrative privileges.
In Windows Explorer, navigate to the following directory:
C:\Program Files\OpenSSH\mValentScripts
Double-click the following file:
mkpasswd.vbs
The script presents the option to create domain only (-D), local only (-L), or both domain and local (-D, -L) user accounts.
Enter the option appropriate to your network environment and click OK.
The script announces successful creation of the files. Click OK to terminate the script and restart the OpenSSH service.
To install the automation module:
Start the Application Configuration Console Server, then start the Client and log in as a member of the Administrators group.
Copy the WindowsRE.jar file from the software distribution disc to a location in the file system.
In the Client, click the Admin menu in the menu bar.
Click Install Extension to open the dialog of the same name.
Select automation as the extension type.
Click Browse to locate the WindowsRE.jar file in the file system.
Click OK to install the automation module.
This creates the Windows Resource Extensions resource specifications under the System > Resource Specifications folder in the Navigator View. These resource specifications have counterpart scripts on the proxy service host that they call to extract configuration and other data from target machines. The scripts are located at the following location:
C:\Program Files\OpenSSH\mValentScripts
Note:
If you install an automation module after redeploying a secondary server, you have to port the AM installation to the secondary server. See Section D.5, "Redeployment and Automation Modules," for details.
|
 Copyright © 2006, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|