Introduction

Table of Contents

  • Introduction
    • Product Availability
    • Overview
    • Important Terminology
    • Planning Application Deployment
    • Dual SVPs
    • Deploying the Service Processor Agent
  • Installation
    • Removing Earlier Versions
    • Software Installation Overview
    • Installation Using the SVP CD-ROM Drive
    • Remote Installation
  • Configuring the Application
    • After Installation
    • Configuring as both Site Manager and SVP Agent
    • Configuring a Site Manager Only
    • Configuring an SVP Agent Only
    • Configuring the Center Tab
    • Configuring the Subsystems Tab
    • Configuring the Notifications Tab
    • Configuring the AutoDumps Tab
    • Configuring Contact Methods with Proxy Servers
    • Finalizing Application Configuration
  • Service Processor Agent Operations
    • Testing SVP Agents
    • Site Manager Operations
    • AutoDump and Microocde Operations
    • Monitoring the Service Processor Agent
    • Troubleshooting
  • Technical Information
    • Miscellaneous Technical Information
    • READ ME
    • Release Notes

All Service Processor Agent applications, documentation, and associated files are:

Copyright © 1995-2021 — Hitachi Vantara All rights reserved.

This tool and associated documentation are intended for internal use only by qualified and authorized personnel of Hitachi Vantara Corporation.


Introduction

Product Availability

The Hitachi Remote Ops Service Processor Agent version D series was developed specifically for the enterprise RAID family of Hitachi Vantara storage products. For the purpose of this document and the Service Processor Agent, the term enterprise RAID systems refers to the following storage systems:

  • Virtual Storage Platform (VSP)
  • Hitachi Unified Storage VM (HUS VM)
  • Virtual Storage Platform F/G 1500/1000 (VSP F/G 1500/1000)
  • Virtual Storage Platform F/G/N (VSP F/G/N 800/600/400/200/100)
  • Virtual Storage Platform 5000 (VSP 5x00/5x00H)

Use Service Processor Agent version D.x for these enterprise RAID systems.

Use Hitachi Remote Ops Monitor Agent version 8.1 or later for monitoring VSP F/G 900/700/370/350/130 systems.

All Service Processor Agent applications, documentation, and associated files are:


Overview

The Hitachi Remote Ops Service Processor Agent monitors VSP, HUS VM, VSP F/G 1500/1000, VSP F/G 800/600/400/200/100, and VSP 5x00/5x00H storage subsystem configurations and for error conditions. The Service Processor Agent reports configuration data to the Hitachi Remote Ops Center daily, and error conditions immediately. The Service Processor Agent can transfer configuration data and report error conditions to the center in one of three ways:

  • HTTPS
  • FTP (deprecated)
  • FTPS (deprecated)

Note: FTP and FTPS contact methods are being deprecated in version D.5. Already defined methods carried over from prior installations will not be deleted, but the application will no longer allow new FTP or FTPS methods to be defined.

Note: When upgrading to version D.5 and later, HTTPS contact methods will be defined for Hitachi Vantara transport locations where missing. In addition, HTTPS polling servers will be added for these locations where missing as well. We encourage you to ensure that the site is able to reach all defined HTTPS transport locations and able to poll all defined poll servers when configuring the application.

To reduce the need for dedicated lines in the data center environment for customer environments that contain more than a single subsystem, one subsystem may be designated the Site Manager (or front*). This system has the physically-connected line and coordinates communications between the Center and other subsystems at the site.

Similar to previous versions (fka Hi-Track), D series has the ability to install the Service Processor Agent on a computer other than a subsystem service processor (SVP) and to designate this system as the Site Manager. In this configuration, all of the actual subsystem SVPs are backs* and none need Internet connectivity.

*See the next section: Important Terminology

All Service Processor Agent applications, documentation, and associated files are:


Important Terminology

Historically, the Service Processor Agent used the term front to refer to a subsystem equipped with a phone line. Backs were other subsystems which communicated with the Hitachi Remote Ops Center through the front. Unfortunately, this terminology doesn't work as well with Service Processor Agent (fka Hi-Track) version B or later because the front could be a completely separate computer system — it may not even be a managed subsystem.

Components of Service Processor Agent version D Series

There are five components of the D series. These are:

  • The Service Manager: This is the GUI application
  • The Site Manager: This service corresponds to the front.
  • The SVP Agent: This service corresponds to the back.
  • The Web Interface: This service enables and hosts the remote operation web interface on the Site Manager.
  • The Service Monitor: This always-on service monitors the Site Manager and SVP Agent and restarts either if they appear to have shutdown unintentionally.

Service Manager

The graphical user interface for configuring the Service Processor Agent's various services is called the Service Manager (pictured below). It is used to manage and configure the services — including starting and stopping them. The Service Manager runs on all systems that the Service Processor Agent is installed on so that you can manage the services on that system. The Service Manager is just a normal Windows application that is launched at login. The system SVPs automatically log in the Administrator account at startup.

SVP Agent

The Service Processor Agent manages communication between the Hitachi Vantara Center and its managed subsystems. In the Service Processor Agent version C/D series, we refer to all storage subsystems under management as a back. Specifically, a back refers to the SVP Agent service running on a managed system.

Site Manager

The front is an instance of the Site Manager service. This service coordinates communication between the Hitachi Vantara Center and whatever storage subsystems it manages. This service can be run on an SVP or on a different computer altogether. If a customer installation consists of a single subsystem, then that subsystem is both a front and a back. In other words, that subsystem will run both the SVP Agent and the Site Manager.

With a customer installation that consists of multiple subsystems, most often, one subsystem will be the Site Manager (which also runs the SVP Agent) and the others are just SVP Agents. For example, a typical customer installation with three subsystems may be configured as follows:

Subsystem | Services Running
Subsystem 1 (VSP) | Site Manager; SVP Agent (back 00)
Subsystem 2 (VSP G1000) | SVP Agent (back 01)
Subsystem 3 (HUS VM) | SVP Agent (back 02)

Web Interface

This feature is only available on versions C.6 and higher.

When enabled, this service allows users without access to a front's SVP to request that a front generate and transfer an AutoDump to the Hitachi Remote Ops Center for one or more of its backs. This service uses IIS Express to host a ASP.NET web interface. As such, to use this feature, the service must be running and this feature must be enabled in the Service Manager on the Site Manager.

In order for users to reach the Web Interface, the port configured during installation is opened by the Web Host and firewall rules are added to allow incoming traffic. The web application can be accessed either from the start menu on a front or accessed via URL. The URL is https://IP:PORT/ where IP is the front's IP address and PORT is the port configured during installation (the default value is 4431).

All Service Processor Agent applications, documentation, and associated files are:


Planning Application Deployment

Before beginning the installation procedure in a data center with multiple subsystems, you will need to do some planning and ensure that you have some information at hand.

First, identify the computer system that will function as the Site Manager. This may be a VSP, HUS VM, VSP F/G 1500/1000, VSP F/G 800/600/400/200/100, VSP 5x00/5x00H, or it may be a separate computer system. The Site Manager serves as the communication channel between the center and all of the subsystems at a customer site. There must be one (and may only be one) Site Manager for a group of one or more VSP / HUS VM / VSP F/G 1500/1000 / VSP F/G 800/600/400/200/100 / VSP 5x00/5x00H subsystems networked together and sharing a single line.

At a customer site equipped with only a single subsystem, most often that system will be configured as both the Site Manager and SVP Agent. This means that it needs to be equipped with a network line if it is to communicate with the Center.

The following lists enumerate the prerequisites for the Site Manager and SVP Agents.

Prerequisites for Installation

A system running Microsoft Windows Server 2008 SP2 or later, Windows Vista SP2 or later, or any newer version of the Microsoft Windows OS.

Prerequisites for the Site Manager

The Site Manager needs:

  • TCP/IP connectivity to the public Internet if communications with the center are to be via FTP.
  • TCP/IP connectivity to each subsystem SVP monitored by the Site Manager.
  • The following ports open*: 2056, 2057, 2058, and 2059.

Prerequisites for the SVP Agents

The SVP Agents need:

  • TCP/IP connectivity to the Site Manager.
  • The following ports open*: 2056, 2057, 2058, and 2059.
  • Outbound HTTPS access to port 443 for transferring data.

Prerequisites for the Web Interface

The Web Interface:

  • The IP address or hostname of the Site Manager.
  • An alternate port to use for the Web Interface if the default port of 4431 is already in use. The chosen port must be open between the host and the Web Interface's users.

General Planning

Before beginning any software installation, prepare notes including:

  • The serial numbers and IP addresses of each subsystem to be managed by the Site Manager.
  • The IP address or hostname of the Site Manager.

*Open ports: Use the Windows Firewall applet in the Control Panel to check or set port settings. (The Windows Firewall applet is installed as part of Windows XP Service Pack 2 or later.)

All Service Processor Agent applications, documentation, and associated files are:


Deploying on Dual-SVPs

Installing the Service Processor Agent at a customer site with only a single system is simple. Just follow the installation procedure and then follow the configuration directions for configuring the Service Processor Agent as both Site Manager and SVP Agent. (But see the note below about dual SVPs before moving on.)

However, it is slightly more complicated to install the Service Processor Agent at a site equipped with multiple subsystems where one of them (or a separate computer) will be used for the Site Manager. This section sets forth the recommended order and best practices for site installations.

Note Regarding Dual-SVPs

This note relates to VSP, VSP F/G 1500/1000, and VSP 5x00/5x00H subsystems only because dual-SVPs are not an option offered for NSC, HUS VM, and VSP F/G 800/600/400/200/100 subsystems.

On VSP, VSP F/G 1500/1000, and VSP 5x00/5x00H systems equipped with dual SVPs, the Service Processor Agent must be installed on both SVPs to take advantage of the intended redundancy of dual SVPs.

In this documentation section (and elsewhere throughout the documentation), references are made to installing the Service Processor Agent on a VSP, or VSP F/G 1500/1000 and no mention may be made of a standby SVP. If a VSP, or VSP F/G 1500/1000 is equipped with dual SVPs, you must be sure to install the Service Processor Agent on both SVPs.

If a system is equipped with dual SVPs, install and configure the Service Processor Agent on the primary SVP first and then install it on the standby SVP. When you install the Service Processor Agent on the standby, a dialog will pop up when the Service Processor Agent detects that it is running on the standby SVP.

Click Yes to migrate the configuration from the primary to the standby.

Note: If you accidentally install the Service Processor Agent on the standby before installing it on the primary, the settings will populate once you install and configure the Service Processor Agent on the primary SVP, so long as (1) the IP addresses of the primary and standby SVPs are explictly configured on the primary SVP or the primary SVP is able to automatically determine the IP address of the standby SVP based on the recommended default IP addresses defined in the product maintenance manuals and (2) the primary SVP is able to communicate with the IP address of the standby SVP are.

Defining the IP addresses of the Dual SVPs

If either the primary or standby SVP uses a different IP address convention than recommended in the maintenance manuals, you'll need to define the IP addresses of both on the primary SVP. This can be done by opening the Subsystems Properties and entering the IP addresses of the primary and standby in their respective fields.

The SVP Agent must be running on the standby SVP in order for the primary SVP to update the standby SVP with these settings.

After you have installed the Service Processor Agent on both the primary and the secondary, you need only make any configuration changes on the primary. Whenever you change the configuration on the primary and click OK or Apply, the Service Processor Agent will automatically migrate the new settings to the standby.

If a standby SVP is installed and running, and the Service Processor Agent on the primary is unable to migrate a configuration change to the standby, you will be notified with a dialog box message:

If you see this message, check that the Service Processor Agent is running on the standby, and consider that if you have made any changes to the port settings on the primary, these settings must also be made on the standby.

To fully test both SVPs, after you have tested the functionality of the primary SVP, perform an SVP swap. After a few minutes you can reestablish your Remote Desktop session to the new primary SVP. It will be at the same address as the old one — i.e. 126.x.x.15. View the log files to verify that when the services started, they recognized that the SVP was in standby mode, then switched to primary mode and restarted. If you perform this test, don't forget to perform a swap again to return the actual primary SVP to primary mode. And finally, wait for the swap to complete and ensure that the Service Manager comes up again properly on the new (original) primary SVP.

All Service Processor Agent applications, documentation, and associated files are:


Deploying the Service Processor Agent

Deploying Service Processor Agent

Deploying in a Multiple Subsystem Environment

Deploying the Service Processor Agent in a multiple subsystem environment is not difficult. These recommendations are just presented to ease the process and to reduce the number of trips you need to make to each subsystem on the network.

Network IP Address

Generally, we recommend that you use the subsystem's private LAN addresses where possible. This will reduce the likelihood of complications from the customer's switches, routers, gateways, etc., not to mention avoiding competition for network bandwidth on the customer's LAN.

However, public LAN settings may be used for a Service Processor Agent LAN. Just ensure that you have TCP/IP connectivity between the Site Manager system and all SVPs. In addition, TCP/IP packets addressed to certain ports must be able to transit the customer network. See the previous section titled Planning Application Deployment for the ports used for intersystem communications.

Installation Order

The quickest way to deploy the Service Processor Agent at a site with multiple subsystems is to install the application on the Site Manager (front) system first. Complete the configuration for the front system and start both of the front and back services. You should finish the configuration on the Site Manager and start that service first. If you do, the backs will self-register with the Site Manager when you install and start the SVP Agent service on the backs. That way, you don't have type in IP addresses or serial numbers.

Then, one by one, go to each back system and install and Configure it as an SVP Agent only .

You will need to provide the address for the Site Manager system (the front — which you installed first). On each back system, after you install the software and specify the address of the Site Manager, open the agent log (which will initially be empty) and apply your settings and start the services. Watch the startup messages in the log. You should see a log message indicating that the SVP Agent registered with the Site Manager (if the Site Manager service is running).

When you have finished configuring the each of the backs (SVP Agent-only systems), return to the Site Manager system and bring up the Service Manager user application. Click on the Subsystems tab and look at the list of subsystems under management. You should see an entry in the list for each back that you configured.

Next, open the Site Manager log on the front. Then click the Subsystems tab and click the button labelled View Logs. This will open the Agent log on each back system. Now go back to the General tab and click the button labeled Arrange. This will line up the log windows on the right side of the screen so you can see them easily. Next click on the Utilities tab and do a manual transfer. Be sure to generate new data files since this is the first time that the Service Processor Agent is running on these system. There will be no data files to send in a manual transfer unless you generate them. Select either a daily or weekly call (preferably weekly) and initiate the transfer. Watch the logs as the data files are generated on each back system. When data file generation is complete, the Site Manager will contact the Hitachi Vantara Center. Watch this as it happens in the Site Manager log.

All Service Processor Agent applications, documentation, and associated files are:


Removing Earlier Versions of the Service Processor Agent

Removing Earlier Version of the Service Processor Agent or Hi-Track

Removing versions B.x or C.x

There are two recommended ways to remove versions B.x or C.x before installing the latest version. You may use the Service Processor Agent installer by clicking on setup.exe. When the installer prompts you the choices "Repair Service Processor Agent" and "Remove Service Processor Agent", select the latter and click OK. Additionally, you may remove the previous version manually by following these steps:

  • Establish a Remote Desktop connection to the SVP
  • Open Control Panel and navigate to Program and Features
  • Select Service Processor Agent (versions D.3 and later) or Hi-Track (versions D.2 and prior) and click Uninstall

Note: uninstalling Hi-Track B.x or C.0 does not remove some of the configuration files. This is so that when you install HiTrack C.1, you do not need to redefine the system configuration.

Removing Hi-Track 8.x or 9.x

If you are installing the latest Hi-Track version on a subsystem SVP currently configured with Hi-Track 8.x or 9.x, you must manually remove Hi-Track 8.x or 9.x before beginning the Hi-Track version C.1 installation. To remove Hi-Track 8.x or 9x, follow the directions below:

  • Establish a Remote Desktop connection to the SVP.
  • Open Windows Explorer and navigate to the directory C:\Documents and Settings\Administrator\Start Menu\Programs\Startup
  • Delete the shortcut in this directory named Hi-Track.
  • Reboot the SVP.
  • Re-establish your desktop connection to the SVP and launch Windows Explorer again.
  • Delete the directory C:\HDS. If you don't reboot the SVP, you may not be able to delete this directory.

All Service Processor Agent applications, documentation, and associated files are:


Software Installation Overview

The service processors (SVPs) of the large RAID subsystems are headless systems. That is, they are not laptop PCs nor do they have attached monitors, keyboards, or pointing devices. As a result, most SVP administration is done via Microsoft Remote Desktop connections from other systems. Because of this, the installation CD does not have an auto-run feature to launch the installation program when the CD is inserted into a CD drive.

If you have physical access to the subsystem and can insert the Service Processor Agent CD into the CD-ROM drive of the SVP, you will follow a slightly different procedure than if you must install the software completely remotely. If you have access to the subsystem CD-ROM drive, you will follow the directions in the section entitled Installation Using the SVP CD-ROM Drive. If not, you will follow the directions in the section entitled Remote Installation.

The Hitachi Vantara VSP, VSP F/G 1500/1000, and VSP 5x00/5x00H subsystems (as opposed to the HUS VM and VSP F/G 800/600/400/200/100) may be configured as dual-SVP systems. With dual SVPs, the Service Processor Agent must be installed on both SVPs to take advantage of the SVP failover mechanism.

For dual-SVP systems, plan to install the Service Processor Agent on the primary SVP first. See the section entitled Dual SVPs for more detailed information about installation on systems configured with dual SVPs.

All Service Processor Agent applications, documentation, and associated files are:


Installation Using the SVP CD-ROM Drive

If you have access to the subsystem SVP, the easiest way to install version D.x is using the SVP CD-ROM drive. Follow the directions below to install Hi-Track using the SVP CD-ROM drive. If the SVP does not have a CD-ROM drive or you do not have physical access to the SVP, you can install the Service Processor Agent remotely, but the procedure is a little different. Skip to the section entitled Remote Installation if you need to install the Service Processor Agent remotely.

  • Insert the Service Processor Agent D.x CD into the CD-ROM drive of the SVP.
  • Launch a Remote Desktop session into the SVP.
  • Open Windows Explorer and navigate to and open the CD-ROM drive.
  • Double-click the autorun.hta file in that directory.
  • Close or minimize any other open windows so you can see prompts.

During the installation process, operating system prerequisites may be installed if it is not already installed on the system. For this reason, the installation may be as quick as a few seconds, or take as long as several minutes. You may also be prompted to reboot the SVP after installation of one of the components. If so, reboot the SVP and begin the installation process again, which will skip over already installed prerequisites.

See Prerequisites for Installation for the components that may or may not be installed.

After the installation completes, you should be prompted to Launch the Service Manager program. At this point, proceed to the Configuring the Service Processor Agent section.

All Service Processor Agent applications, documentation, and associated files are:


Remote Installation

Note: If you intend to install the Service Processor Agent C/D Series on a system currently running a previous version of Service Processor Agent (fka Hi-Track), you must remove the previous version before installing versions C.x/D.x. See the Removing Earlier Versions section for detailed directions for removing the old version of the Service Processor Agent.

If physical access to the SVP CD-ROM is not available or practical, you may install the application remotely. The key is to get the installation files onto the SVP. Preferably, you should FTP the installation files to the SVP. However, you may also use Remote Desktop, following these steps:

On your local computer:

  • Insert the Service Processor Agent CD into your local CD-ROM drive.
  • Launch Remote Desktop.
  • In the Computer box, enter the IP address of the SVP.
  • Click the Options>> button to expand the dialog.
  • For user name, enter Administrator.
  • Enter the password for the Administrator account.
  • Click the Local Resource tab.
  • In the Local devices group box, check Disk Drives.
  • Click the Connect button.

On the SVP:

  • Open Windows Explorer
  • Copy the Service Processor Agent Setup Image directory from the CD media onto the C drive of the SVP.
  • Navigate into the new Service Processor Agent Setup Image folder on the C drive.
  • Execute the autorun.hta program by double-clicking it.
  • Close or minimize any other open windows so that you can see prompts.

All Service Processor Agent applications, documentation, and associated files are:


After Installation

After the installation program finishes, you should see the Service Manager application (pictured below). You should also see a new icon in the system tray.

Don't click any buttons yet at this point.* What you will do next is customize the installation and (ultimately) click OK. Again, don't do this yet, but when you are done configuring the Service Processor Agent and click OK, the Service Manager will close. You can open it again by double-clicking on the Service Manager icon in the system tray (or by right-clicking on it and choosing Open Service Manager.

* The reason not to click OK yet at this point is that when you click OK (or Apply) the Service Manager will validate the settings you have entered: but if you are seeing this application for the first time, you haven't entered any settings yet.

All Service Processor Agent applications, documentation, and associated files are:


Configuring as both Site Manager and SVP Agent

To configure an installation as both the Site Manager and SVP Agent, ensure that the checkbox labeled This system is the Site Manager is checked under the General tab.

Configuring the Site Tab

Click the Site tab of the Service Manager.

On the Site tab, enter the pre-assigned site ID for this customer, and optionally the customer's organization name in the text box labeled Customer.

Enter the name of the service provider in the Service provider name field. On new installations, this will default to "Hitachi Vantara". The value you enter here will be used in the email messages that the Site Manager sends so that the messages are somewhat customized to the provider. Partner service providers may prefer that their company name be displayed in email messages instead of "Hitachi Vantara".

If SIM messages are to be reported to Hitachi Remote Ops, check the Report SIMs checkbox.

If you do not want to display the IP addresses of the SVP Agent Systems, check the Hide local IP addresses checkbox.

If the Resend uncompleted SIMs checkbox is checked, the Site Manager will resend any and all SIMs that have not been marked completed in the SVP each day until all SIMs are marked complete. Do not check this checkbox unless you want a daily reminder to resolve and complete SIM messages.

The Center Tab

Follow the directions on the page Configuring the Center Tab to populate the controls in this tab.

The Subsystems Tab

Follow the directions on the page Configuring the Subsystems Tab to populate the controls in this tab.

The Notifications Tab

Follow the directions on the page Configuring the Notifications Tab to populate the controls in this tab.

The Polling Tab

Follow the directions on the page Configuring the Polling Tab to populate the controls in this tab.

Finalizing Application Configuration

Follow the directions on the page Finalizing Application Configuration to finish configuring the Service Processor Agent as both a Site Manager and SVP Agent.

All Service Processor Agent applications, documentation, and associated files are:


Configuring a Site Manager Only

Follow the directions in this section to configure the Service Processor Agent as a Site Manager on a standalone computer (not on an SVP).

The Site Manager is the system that communicates with the Center.

The General Tab

To configure a Service Processor Agent installation as a standalone Site Manager, make sure the checkbox on the General tab labeled This system is the Site Manager is checked. Your Service Manager should look like the graphic below.

The Center Tab

Follow the directions on the page Configuring the Center Tab to populate the controls in this tab.

The Subsystems Tab

Follow the directions on the page Configuring the Subsystems Tab to populate the controls in this tab.

The Notifications Tab

Follow the directions on the page Configuring the Notifications Tab to populate the controls in this tab.

The Polling Tab

Follow the directions on the page Configuring the Polling Tab to populate the controls in this tab.

Finalizing Site Manager Configuration

Follow the directions on the page Finalizing Configuration to finish configuring the Site Manager.

All Service Processor Agent applications, documentation, and associated files are:


Configuring an SVP Agent Only

To configure an installation as an SVP Agent only, on the General tab of the Service Manager application, uncheck the This system is Site Manager checkbox.

After you uncheck the checkbox, you will be presented with dialog box shown below. Use this dialog box to enter the IPv4 or IPv6 address of the system that will be (or is) the Site Manager.

Next, click the Subsystem tab on the Service Manager.

On a Site Manager (not this configuration), this tab displays a list of subsystems under management by the Site Manager. With this configuration (the Service Processor Agent configured as an SVP Agent only), this list box should contain the definition of this single subsystem SVP. Notice in the graphic above the first column in the list has the word this in parentheses.

If the Service Manager was able to communicate with the SVP at the time it was first run, the system serial number should already be correct as should be the address — which should be localhost. If either of these values is incorrect, edit the subsystem properties to correct the situation.

The SVP Agent can be further configured from the Properties menu to define an explicit IP address to use when registering with a Site Manager. Enter the desired address in the IPv4 or IPv6 Registration Address field. You must enter the IP address in this field if the back is on a different subnet than the front. The entered IP address can be either IPv4 or IPv6 (if IPv6 is supported on the platform OS). If the latter, the IPv6 addressed should be wrapped in square brackets and the scope ID (denoted by the ‘%’) should be omitted.

Finally, return to the General tab and click Apply. The Apply button (and the OK button) will perform some rudimentary checks on your configuration. You may receive one or more error messages and possibly some warning messages. Correct any errors and click the Apply button again.

When your configuration appears to be OK, the Service Manager will ask if you want to start the SVP Agent service. If you click Yes to the prompt to start the service, it should start up and the red visual cue should turn green.

Click any enabled log buttons on the General tab if you would like to watch the startup process. Close the log windows when you are finished viewing them.

Click the Utilities tab, and click the Test Now button to test network connectivity to the Site Manager (if the front service is running on the Site Manager).

Click OK to minimize the Service Manager to the system tray.

All Service Processor Agent applications, documentation, and associated files are:


Configuring the Center Tab

This tab has a list box, labeled Contact Attempt Sequence, which represents the different methods that the Site Manager will use to contact the Hitachi Remote Ops. By default, multiple HTTPS destinations are defined so that the application can failover to another option if a particular HTTPS connection cannot be established successfully.

The Service Processor Agent offers a way to automatically add the proper contact methods. These methods, if added, will pre-populate the needed contact method info for you so that you only need to verify the information is correct and click OK.

The Service Processor Agent also allows for the destination of custom HTTPS destinations in case a new HTTPS destination is needed beyond the default destinations that can be automatically configured.

To add a contact method, click the Add button from the Center tab of the Service Manager. This will open the Add Contact Methods dialog.

Adding Contact Methods

Decide which type of contact methods you want to add, and the destinations to add, and click Continue.

Type of Contact Methods

From version D.5 onwards, the only type of protocol it is possible to define is an HTTPS transport. Prior versions of the application allowed a customer to define alternate FTPS (FTP secured with SSL) or FTP contacts. It is not longer possible to define new FTP or FTPS destinations. However, previously defined FTP and FTPS contact methods will persist from prior versions of the application after upgrading to version D.5 or higher.

It is also possible to introduced a new transfer method called Manual. When this contact method is added, the Site Manager stores the collected data (Config.zip, csv.zip, Dat.zip, performance data) in the C:\HDS\ directory and will not transport them to the centers. The purpose of the Manual method is to allow the Service Processor Agent to be used at customer sites that do not support a direct connection link to the Hitachi Remote Ops. Using the Manual method, field engineers can copy the files into a different computer and transfer them from there to the Hitachi Remote Ops. Note that you need to remove the already defined transfer methods before adding the Manual method.

Destinations

You can choose to add the two older transfer servers (ushtinet01,02), the two newer transfer servers (usdenhtinet01,02), or all four servers. The two newer transfer servers require TLS 1.2 to be enabled in Windows. TLS 1.2 is not supported at all in Windows Vista or Server 2008, and may need to be manually enabled in Windows 7 or Server 2008 R2.

Contact Method Properties

An HTTPS contact method definition needs, at a minimum, an address, username, and password. At some customer sites, you may need to define the proxy server attributes to get HTTPS transfers working properly.

Checking Validate Server Certificate will make sure that the HTTPS certificate validates properly.

The Times to attempt control defaults to a value of 4. This means that the Site Manager will attempt to contact the center four times using this method before failing over to any secondary or additional contact methods. Change this value if you prefer a different value. Note that the number you enter here affects the number of times that the Site Manager will retry this call method before moving on to the next defined call method.

Notice the Test button on this dialog. In the graphic above, the Test button is disabled because the Site Manager service has not yet been started. After you complete the configuration and start the services, if you return to this dialog at a later time you can test a contact method by clicking the Test button. (Note that to see the progress of the test call, you will have to view the Site Manager log.)

Next click OK in the Contact Method Profile dialog. This will return you to the Center tab.

Finishing Contact Method Configuration

Now you should see your contact methods in the list. The Maximum sequence passes control allows you to adjust how persistent the Site Manager will be in contacting Hitachi Vantara before failing completely. You can select any value between 1 and 99. If you choose 4, for example (which is the default), the Site Manager will make four complete passes through the contact method list before giving up. The contact methods will be attempted in random order.

The Call Time group box allows you to set the time of day that calls will occur on. The Weekly day drop list allows you to choose the day of the week that the Site Manager should considers the daily call to be a weekly call.

You can click the Randomize button to cause random selection of different values for both the time of the daily calls and the weekly call day. When the Service Manager starts up for the first time, the daily call time and day are randomized. We recommend that you leave the call time at its default random value to help normalize the times that sites call into the Hitachi Remote Ops. Note: the value that you set for the daily call time may be changed by the Center during a daily or weekly call.

We recommend that you leave the Automatically send support data to Hitachi Vantara option checked. This ensures that the configuration data is sent to Hitachi Vantara on a daily basis. The difference between disabling this option and using a Manual contact method is that SIM data continues to be transferred to Hitachi Vantara as long as there is a valid contact method, regardless of this setting.

All Service Processor Agent applications, documentation, and associated files are:


Configuring the Subsystems Tab

Click the Subsystems tab.

Adding Additional Subsystems

This panel displays the list of subsystems under management by this Site Manager. If this Site Manager is running on an SVP, the back service will discover the subsystem type and serial number and populate the list with an entry for the local subsystem.

If the site has additional subsystem that will be reporting through this Site Manager system, the easiest way to configure the remaining subsystems is to finish the configuring this system as the the Site Manager and start the services, then install the Service Processor Agent on each SVP Agent-only (back) system. When you configure a site this way, the backs will self-register with the Site Manager and you won't have to type in serial numbers or IP addresses.

However if you prefer (or if you have already installed the Service Processor Agents on the backs), you can proceed to define the backs in the Site Manager. To add additional subsystem definitions this way, click the Add button. This brings up the Subsystem Properties dialog box.

Type in the IP address of the subsystem you are adding and click OK.

Note: If an added subsystem does not exist on the same subnet as the Site Manager, you will have to explicitly define the IP address for that subsystem to use in that systems SVP Agent. See the section Configuring an SVP Agent Only for more info.

When you return to the Subsystems tab, you will see your new entry in the list of subsystems. If the Service Processor Agent is already installed and running on this subsystem, the Service Manager will automatically discover the subsystem type. If the back service is not already installed and running on the subsystem, the Type will display as "Unknown" until communications can be established with the subsystem.

If the back service on the subsystem is running and communications are normal, you can double-click on the subsystem in the list to bring up the Subsystem Properties dialog again.

Notice that this time, you cannot edit the IP address of the subsystem. This is because the Site Manager is already communicating with the subsystem and has validated this information.

The controls you can use on this panel include an Allow FC-GS queries checkbox and View Log, Generate Data Files, Generate Dump Files and Transfer Dump Files buttons.

By default, the Allow FC-GS queries checkbox is checked. During the data file generation process, two of the data files generated are the result of calling an API in the SVP microcode, which in turn, performs an industry standard FC-GS RNID query to attached host HBAs and switches. Under certain hardware/driver combinations, this query could result in problems with attached hosts or switches. If this checkbox is checked, the back service will generate these data files. However, removing the check from this checkbox will cause the back service to skip the generation of the FC-GS data files.

The Generate Dump Files button was introduced in version C.6 of the Service Processor Agent. This feature allows you to generate and transfer an available AutoDump to the Hitachi Remote Ops.

Click Close to close the Subsystem Properties dialog.

All Service Processor Agent applications, documentation, and associated files are:


Configuring the Notifications Tab

The Notifications Tab and Email Events

Click on the Notification tab in the Service Manager.

Occasionally customers have requested the ability to be informed if their storage subsystem experiences any problems. This feature is in response to this request. Email event notification in no way replaces the current daily call or incident call mechanisms. It is unrelated and is not a new transport method.

Consider all of the ramifications of email notifications prior to enabling this feature. (For example, if the Site Manager is configured to resend uncompleted SIMs each day, email messages will also be resent each day until all SIMs are completed. This feature may also result in additional contacts from the customer, possibly including duplicate cases being opened if a customer responds to an email.) If you configure email event notification at the request of a customer, be sure to explain explicitly to them that they do not need to take actions based on email messages they receive. Hitachi Vantara will still be notified of events and cases will be opened in the usual way. You may want to consult with your manager before enabling this feature.

There are five events that can cause email messages to be sent. These are:

  • When SIM messages occur
  • Site Manager is unable to make contact with Hitachi Vantara
  • Site Manager is unable to make contact with one of the monitored subsystems
  • GSC requests to remotely update the microcode
  • GSC requests a dump file to be generated and transmitted to Hitachi Vantara

Whether or not the Site Manager sends an email for each of these events is individually configurable. In other words, you can configure the Site Manager to send email messages only when SIMs occur, only when the Site Manager cannot contact Hitachi Remote Ops, both, or neither.

For the Site Manager to send email messages, it is necessary to know the IP address or host name of the customer's email server, and whether or not authentication is required by that server. If authentication is required by the customer's email server, you will need to obtain an SMTP user account and password from the customer for use with their email server.

Check the AutoDumps checkbox if you want the Site Manager to send an email when it receives a request to generate a dump. This request can come from Hitachi Remote Ops, from the Site Manager due to a SIM-AutoDump trigger, from the Service Manager, or from the Web Interface.

Check the Center transport failure checkbox if you want the Site Manager to send an email when it is unable to contact the Hitachi Remote Ops. The Site Manager will not send an email for every failure to contact the Center. It will send one email message after it has exhausted all of the retries of each configured contact method and exhausted the number of sequence passes (passes through the entire contact method list) configured on the Center tab. This is a fairly rare occurrence, and is indeed a condition about which a CSR and a customer should want to be notified.

Check the Microcode updates checkbox if you want The Site Manager to send an email when it receives a request to upgrade microcode, and when the upgrade completes or returns an error. This request can only come from Hitachi Remote Ops.

To configure the Site Manager to send email messages for SIMs, click on the Notification tab of the Service Manager application, check the SIMs checkbox. Note that SIM messages are not summarized. Use the SIM Severity combo box to send notification email based on the level of SIMS. For example, you can select Acute and Serious from the list to limit email reporting to SIMS with these levels. The default value of the combo box is “All” indicating that Site Manager should send an email for each SIM that occurs.

A valid, non-manual contact method must also be defined in order for SIM notification to occur. Having no contact methods configured or a manual ontact method configured will preempt SIM processing and bypass any SIM email notification.

Check the Subsystem connection failure checkbox if you want the Site Manager to send an email when it is unable to contact a subsystem for more than one hour. The Site Manager will not send an email for every failure to contact the subsystem.

Mail server: enter the host name or IP address of the customer's mail server. The customer will have to provide this information.

Port: Enter the SMTP port number. The standard SMTP port is 25.

From: A "From" identity is required. If the customer's email server requires authentication, you will need to put the new email address obtained from the customer in this control (for example "HDS_Support@customername.com. If the customer's email server does not require authentication, you can often supply a fictitious (but more descriptive) identity, for example "HDS-USPV-10032@customerCompany". (Either way, what you supply in the From address needs to look like a valid email address and include the @ sign and no space characters. Also be aware that a fictitious email address may result in email messages from the agent to be marked as spam by filters. However with most filters you can usually mark them as "not spam".)

Use authentication, SMTP user, and password: When you get permission or a request from the customer to send email messages, you will need to collect some information from them about their mail server: its host name or IP address and whether or not it requires authentication from inside of their firewall are the first two questions to ask. It is common for organizations not to require authentication to send an email from inside of their firewall. If their server does require authentication, the next question to ask is if they will provide you with an email account for the Site Manager to use. If they provide you with an email address to use, use that address in the From box, check the Use authentication checkbox, and enter the SMTP username and password in the text boxes provided.

Use SSL: Specifies whether SSL is used to access the specified SMTP mail server. The mail server is required to support secure connections and advertises STARTTLS in the response to the EHLO command.

Email addresses: enter each email address you want the Site Manager to send messages to in this text box. Separate the list of addresses by putting each one on a separate line.

Send email as plain text only: choose this option to send emails in a plain text format instead of using a rich text/HTML format.

Send Test Email: Be sure to test your email settings and addresses before leaving the site. To test your settings, click the button labeled "Send Test Email". The Site Manager will send a test message immediately or describe any problems it encounters with your email settings.

All Service Processor Agent applications, documentation, and associated files are:


Configuring the Polling Tab

On the Polling tab, the default and recommended setting is to enable everything within the Polling Requests" panel.

The Enable SIM triggered AutoDump transfer option determines whether or not a SIM can trigger the generation and transfer of a Detail AutoDump. The AutoDump will only be triggered for SIMs with particular reference codes.

The Enable web interface optinos starts and stops the Web Interface. This feature enables users who don't have access to a Site Manager's SVP but who do have access to the web interface to request AutoDump generation and transfer for one of the monitored subsystems.

The Enable Remote Ops requests option starts and stops polling of Hitachi Remote Ops for various requests: AutoDumps, SVP reboot, Daily Call, Software Updates for the SVP Agent. The polling settings can be changed by clicking the Edit Polling Configuration button. Modifications may include the poll watch interval (which must be 200 seconds at the minimum), servers to poll, and the HTTP proxy and authentication needed to reaching the poll servers.

The Enable microcode updates option starts and stops polling of Hitachi Remote Ops for microcode update requests. The polling settings can be changed by clicking the same Edit Polling Configuration button.

All Service Processor Agents applications, documentation, and associated files are:


Configuring Contact Methods for Proxy Servers

The Site Manager allows configured FTP and HTTPS Contact Methods to use several types of proxy servers that may be in operation at customer sites. The types of proxy servers supported are:

  • Simple FTP Proxy
  • SOCKS4 Proxy
  • SOCKS5 Proxy
  • HTTP Proxy

Simple FTP Proxy

The most common type of FTP proxy is a simple FTP proxy. With a simple FTP proxy, a user inside of a corporate firewall can perform FTP connections and transfers with FTP servers outside of the corporate network by connecting to the FTP proxy and when prompted for a username, providing one in the form of username@remotehost. When prompted for the password, you supply the password for the remote FTP server.

To configure the Site Manager to use a simple FTP proxy, put the address of the Hitachi Remote Ops FTP or HTTPS server in the HDS host control and the username and password for that FTP server in the controls immediately below the Hitachi Vantara host labeled Username and Password. In the Proxy Server group box, open the Type drop-down list and select Simple FTP Proxy. Enter the host name or IP address of the client's FTP proxy in their respective controls.

Most of the time, this will be all you need to do. However if the client's FTP proxy is not on the default FTP port of 21, specify the correct port in the Port control.

Occasionally, a simple FTP proxy will require separate login credentials. In this case, enter the username and password in the controls provided.

A completed typical Simple FTP Proxy configuration is pictured in Figure 2.

SOCKS Proxy Servers

To configure the Site Manager for a SOCKS proxy, select SOCKS4 or SOCKS5 as appropriate from the drop-down list and enter the applicable parameters for the SOCKS server. Note that legacy proxy servers such as SOCKS are notoriously problematic.

HTTP Proxies

HTTP proxies expect to send and receive HTTP (web) requests from the Site Manager. For clients equipped with HTTP proxies, enter the address and port of the proxy. Unfortunately, a standard implementation of this type of proxy is elusive.

Open a case with GSC and work through the problem. You may need to work with the client company's IT staff and may need to use tools to capture TCP/IP packets and analyze them to determine the nature of the problem. Do not contact the Hitachi Remote Ops development team directly. When you contact the Hitachi Remote Ops development team, this deprives GSC staff of the opportunity to develop skills and knowledgebase articles to assist others with similar problems.

All Service Processor Agent applications, documentation, and associated files are:


Finalizing Application Configuration

Finishing Up Configuration

Finally, return to the General tab and click Apply. The Apply button (and the OK button) perform some rudimentary checks on your configuration. You may receive one or more error messages and possibly some warning messages. Correct any errors and click the Apply button again.

When your configuration appears to be OK, the Service Manager will ask if you want to start the services. If you click Yes to the prompt to start the services, they should start up and the red visual cues should turn green.

Click any enabled log buttons on the General tab if you would like to watch the startup process.

Click the Utilities tab, and click the Test Now button to test network connectivity to the Site Manager and each SVP Agent.

With both the Site Manager log and Agent logs open in a window so you can see the progress, perform a manual transfer to the Center by clicking the Transfer Now button. We recommend doing a Weekly transfer because a weekly transfer will transfer the system configuration which will then be available to see by Hitachi Remote Ops.

Close the log windows when you are finished viewing them. Leaving them open permanently is not recommended for several reasons: they unnecessarily add to network traffic and overhead, consume memory resources on the SVP, and nobody is there to see them anyway.

Click OK to minimize the Service Manager to the system tray.

All Service Processor Agent applications, documentation, and associated files are:


Testing the SVP Agent

Once you have installed, configured, and started up the SVP Agent service, there's not much to do but test network connectivity and perhaps data file generation. A normal startup sequence looks like the following:

Testing Data File Generation

To test data file generation:

  • Open the Agent log to view the log file (if it's not still open after the above procedures).
  • Click on the Subsystem tab.
  • Double-click the first (only) subsystem in the list.
  • In the Subsystem Properties dialog, click the Generate Data Files button.
  • View the progress in the log.

Testing AutoDump Generation

The site manager must also be running to test AutoDump generation, because the generated AutoDump is transferred to Hitachi Remote Ops (or wherever the transport method points):

  • Open the Agent log to view the log file (if it's not still open after the above procedures).
  • Click on the Subsystem tab.
  • Double-click the first (only) subsystem in the list.
  • In the Subsystem Properties dialog, click the Generate Dump File button.
  • Select the desired AutoDump type from the pop=up window and click Generate.
  • View the progress in the log.

Do note that the subsystem enters a 2 hour lockout period after each successful AutoDump generation, during which any subsequent requests will be refused until the lockout period finishes.

Testing Network Connectivity with the Site Manager

To test network connectivity:

  • Ensure that the Site Manager service is running on the front.
  • Open the Service Manager by double-clicking its icon in the system tray.
  • Select the General tab and ensure that the SVP Agent service is running.
  • Select the Utilities tab and click the Test Now button.
  • View the SVP Agent Connectivity Test report. If it displays the Service Processor Agent version, the back is functioning normally.

On a properly configured back, the network test report should look like this:

If the back cannot communicate with the front, the network test report will look like the following:

The line labeled Site Manager indicates whether the back is able to communicate with the the front. If you see the above error message, it likely indicates that the Site Manager service is not running on the Site Manager.

All Service Processor Agent applications, documentation, and associated files are:


Site Manager Operations

Testing Network Connectivity between the Site Manager and SVP Agents

To test the Site Manager, first establish a Remote Desktop session into the SVP running the Site Manager (or log in to the system in the case of a standalone PC). Then:

  • Open the Service Manager
  • Select the General tab and ensure that the front service is running
  • If the system is on an SVP, also ensure that its back service is running
  • Select the Utilities tab and click the Test Now... button
  • View the SVP Agent Connectivity Test report. If it displays the versions for the Service Manager, the front, and each of the backs (including microcode levels for the backs), then the Service Processor Agent is functioning normally.

The SVP Agent Connectivity Test report will indicate the versions of the Service Manager, the Site Manager, and it will indicate whether or not it is able to communicate with the configured SVP Agents.

The report above indicates that the Site Manager service is running properly, and that the SVP Agents are configured correctly and running.

Manual Transfers to Hitachi Remote Ops

Once you have established network connectivity between the front and all of the managed backs, perform a test contact to Hitachi Remote Ops. To do this, perform the following steps:

  • If the logs are not already open, they can be opened from the General Tab
    • If there are multiple backs being managed, the logs for each can be opened from the Subsystem Properties dialog of each back
  • Click on the Utilities tab of Service Manager on the front
  • Select either a daily or weekly call
  • Check the Generate new data files checkbox
  • Click the Transfer Now button
  • Watch the progress of the transfer in the log viewers. You should see:
    • The file generation progress in each back log
    • When file generation is complete on all the backs, you should see the transfer take place in the front log
    • If the primary transfer method is FTP, after the FTP completes, you should see a test call to the Center take place

All Service Processor Agent applications, documentation, and associated files are:


Polling Operations

AutoDump and Microcode Operations

AutoDumps

There are four methods of generating and transferring AutoDumps to the Hitachi Remote Ops (or wherever the transport method directs). These methods are supported on VSP 5x00/5x00H, VSP F/G/N 800/600/400/200/100, VSP F/G 1500/1000, HUS VM, and VSP:

  • SIM Triggered AutoDumps
  • Service Manager
  • Web Interface
  • Dump Polling

Any subsequent requests will be refused by the subsystem until the dump period finishes.

AutoDump transfers use the contact methods listed in the Center tab. Follow the directions in the page Configuring the Center Tab to populate and learn how to use the controls on the Center tab.

Note: Dump transfers will time out after 8 hours.

SIM Triggered AutoDumps

The Enable SIM triggered AutoDump transfer option under the AutoDumps tab determines whether or not a SIM can trigger the generation and transfer of a Detail AutoDump. The AutoDump will only be triggered for SIMs with particular reference codes.

Service Manager

From the Service Manager, you can trigger an AutoDump by selecting a subsystem from the Subsystems tab, pressing the Properties button, pressing Generate Dump File tab, and selecting an AutoDump type.

You can view the progress of the AutoDump from the Agent Log and the progress of the transfer from the Site Manager Log.

Web Interface

There are two ways to access the Web Interface:

  • The Web Interface shortcut in the Start menu
  • The address https://IP:PORT/ where IP is the front's IP address and PORT (the default value is 4431) is the port that was configured during installation. IP can also be replaced with "localhost" in the url when on the Site Manager itself.

Either will navigate you to the web application. You will be notified by the browser that the default SSL certificate provided for the site is not trusted and prompted to proceed. After proceeding, the initial administrative login user is "admin" and the password is "default". Upon logging in, the administrator will be prompted to change their password. You may do so or navigate elsewhere.

Additional users may be added by clicking the User navigation link at the top and then the Create a New User link on the User page. Created users can be assigned a role:

  • Viewer: This group can only view a Site Manager's subsystems and the logs.
  • User: This group can only view a Site Manager's subsystems, submit AutoDump requests, and view the logs.
  • Admins: This group can do everything including being able to view a Site Manager's subsystems, submit AutoDump requests, edit the AutoDump Interface's configuration, enable or disable dump and microcode polling, edit users, and view the logs.

In addition, LDAP authentication can be configured by navigating to Configuration, clicking "Edit", and filling out the fields on that page. Once completed, click Test to verify the LDAP configuration. Once verified, an Implement Now button will appear. Re-enter the "Initial Administrator" password, then press Implement Now to commit the changes.

Local authentication may be re-enabled by editing the configuration and clicking Implement Local Authentication. You will be prompted to set up a new "Local Administrator" username and password. Then you will have to click Implement Local Authentication again to commit the changes.

The list of available subsystems to select can be found on the Home page, or a warning message if the Site Manager isn't currently running on the front. Select the desired systems by checking the boxes next to their serial number. When finished with your selection, click Submit Dump. Note that checkboxes will be disabled for unsupported system types.

On the next screen, enter the numerical portion of an SR number if you want to associated the dumps generated with an SR Number. Then select the desired AutoDump type from those available. If batching a request for multiple systems, the dump types available will be limited to those of the system type with the most dump type restrictions, i.e. having a USP V in your list of selected systems means you can't request a batch dump of Mode 31.

Once picked, you'll be prompted to return either to Home or view the progress of the AutoDump request in the Log.

In the Log, you can sort messages by the date range or severity. You can also choose to have the log permanently scrolled to the bottom to view the latest messages as they come in. Also, you can delete a range of messages by clicking Clear and selecting a date range, or save the logged messages to a csv file by clicking Export.

Installing a Customer Certificate

If a customer would like to install their own SSL certificate for the Web Interface, they may do so manually with the following procedure. The customer will need the thumbprint (with white spaces removed) of the certificate to be installed on hand, as well as the port that the Web Interface is bound to.

In this example, the thumbprint will be 01234012340123401234 and the port will be 4431. You will need to replace the thumbprint in the examples with the actual thumbprint of your certificate.

  • Import the customer supplied SSL certificate into the Windows certificate store
    • Open the Command Prompt with administrative privileges
    • Enter mmc to open the Microsoft Management Console
    • Click File
    • Select Add/Remove Snap-in
    • Select Certificates
    • Select Computer account and click Next
    • Select Local computer and click Finish
    • Click OK
    • Expand Certificates (Local Computer)
    • Expand the certificate store that you will be installing the SSL certificate into
    • Right click Certificates
    • Expand All Tasks and select Import
    • Follow the prompt to select the customer supplied SSL certificate and input into the certificate store
    • Repeat step l through step m to import the certificate's private key if the private key was not packaged together with the certificate in a standard encrypted file
      • If the imported certificate from this step does not display a key symbol in the top left corner of the certificates icon, that means only a certificate has been imported and that you need to import the certificate's private key as well.
  • From a command prompt, run netsh http delete sslcert ipport=0.0.0.0:4431
    • Replace 4431 with the port configured at installation if the default configuration was not used
  • From a command prompt, run netsh http add sslcert ipport=0.0.0.0:4431 certhash=thumbprint appid={GUID}
    • Replace 4431 with the port configured at installation if the default configuration was not used.
    • Replace thumbprint with the thumbprint of the customer supplied SSL certificate
    • Replace GUID, but not the braces surrounding it, with the GUID of the Hitachi Remote Ops Service Processor Agent version installed. See Miscellaneous Techincal Information for the list of GUIDs for each version of the application.

Remote OPs Polling

From the Site Manager, you can enable Remote Ops polling from the Polling tab and edit the poll configuration by pressing Edit Polling Configuration.

Remote Ops polling allows for a variety of remote support operations including AutoDump acquisition, remotely triggered DailyCall, and software updates of this application.

If enabled, the Site Manager will poll at the configured number Poll Watch Interval seconds, cycling through the servers listed under Poll Servers. If a request for the SiteID exists, the Site Manager will trigger and transfer an AutoDump for the requested AutoDump type and subsystem serial number.

Note: for this feature, the Site Manager must be able to reach poll servers, so a proxy and authentication may need to be configured for polling.

Remote Microcode Updates

From the Site Manager, you can enable remote microcode update polling from the Polling tab and edit the poll configuration by pressing Edit Polling Configuration. The same settings are used for both dump and microcode polling.

It is not possible to trigger a microcode update through the Service Processor Agent directly from the site itself for security reasons.

All Service Processor Agent applications, documentation, and associated files are:


Monitoring the Service Processor Agent

When the Service Processor Agent starts up for the first time, it creates a directory structure under C:\HDS on the C: drive of the installation system for output generated by application. Detailed log files are generated and placed in the directory C:\HDS\Logs. There are five types of log files:

  • Site Manager logs
  • SVP Agent logs
  • Service Manager logs
  • Transport Logs
  • Remote microcode update logs (for F/G/N 800/600/400/200/100)

For the first three log types, new log files are created each day, with the log's date becoming a part of the file name. For example, for February 14, 2018, the filenames would be 20180214-Front.log, 20180214-Back.log, and 20180214SvcMgr.log.

Of these dated log files, logs older than 30 days are deleted each day.

The transport log is named simply Transport.log. This log contains a record of every transfer attempted from this Site Manager and whether the transfer succeeded or failed. This log is never deleted or overwritten.

Remote microcode updates on the VSP F/G/N 800/600/400/200/100 (and not the other system types) create a separate log to monitor the updating of the DKC.

Viewing Log Files in the Service Manager Application

From the Service Manager, you can view the current day's local log files by clicking the appropriate button on the General tab of the Service Manager. If the installation is functioning as both a Site Manager and an SVP Agent (both front and back), you can view both the front and back logs by clicking the appropriate button on the General tab. Additionally, you can view the Service Manager log by clicking the button labeled Service Mgr Log. The transport log cannot be viewed through the user interface.

Note: the log buttons in the Service Manager will display the log file for the current day only. To view previous log files, open the directory C:\HDS\Logs, select the log you would like to view, and double-click it to open it in Notepad.

Viewing Log Files Remotely

From the Site Manager, you can also view the SVP Agent logs of remote SVP Agents. To do this:

  • Go to the Subsystems tab
  • Double-click the subsystem in which you are interested
  • Click View Log

Note: the log buttons in the Service Manager will display the log file for the current day only. To view previous log files on a remote SVP Agent you need to establish a Remote Desktop connection into the remote SVP, open the directory C:\HDS\Logs, select the log you would like to view, and double-click it to open it in Notepad.

Sending SVP Dumps to the Hitachi Remote Ops

From the Site Manager, you can trigger sending a dump from any SVP Agent to Hitachi Remote Ops. To do this:

  • Go to the Subsystems tab
  • Double-click the subsystem in which you are interested
  • Click Transport Dump Files...
  • Select the dump file you want to send and click Send

Note: sending a dump file to the Center this way does not create a new dump file. It only allows you to choose an existing dump file on the particular SVP Agent. If you need to send a current dump file, you must either remote desktop to the SVP and generate the dump file first or use one of the AutoDump generation methods listed in AutoDump Operations. Sending a dump will not generate new data files. If you want to include the dump file with up to date data files, click the Generate Data Files buttons and wait for the file generation to complete before clicking the Send Dump button. (You can monitor the progress of file generation by clicking the View Log button if the log isn't already open.)

Note: dump transfer will time out after 8 hours.

Testing the Configured Contact Mechanism

On the Utilities tab of the Service Manager Application (on the Site Manager), you can perform a test call to the Center, or test a daily or weekly call. Clicking the Transfer Now button will cause the configured contact sequence to place a daily or weekly call to the center. (You can monitor the progress of the contact by viewing the Site Manager and SVP Agent logs.)

All Service Processor Agent applications, documentation, and associated files are:


Troubleshooting

Problems with the Setup program (Service Processor Agent Setup.exe)

The setup program checks to see if required components are installed on the target system and installs them if not, then it installs the Service Processor Agent. No problems with the setup program are known or anticipated, however, in the event that the setup program does not operate as expected, you can perform the Service Processor Agent installation manually.

Previous versions of the Service Processor Agent (fka Hi-Track) B.x had a dependency on the Microsoft .NET Framework version 1.1. Version B.7 and later used version 2.0 of the .NET Framework. Version C.4 and later used version 4.0 of the .NET Framework. Current versions, starting with version C.D and onwards, use .NET Framework 4.6., which has a dependency on an operating system component called the Windows Installer 3.1. This component is installed automatically by Windows XP Service Pack 2. If you need to install the Service Processor Agent on a system that has not been updated to Service Pack 2, the preferred path of action is to upgrade the SVP to SP2 and apply all additional required patches. However, if this is not possible, you may upgrade the Windows Installer by applying the patch located in the \Prerequisites directory of the installation media. After applying SP2 or manually applying the Windows Installer patch, you may install the Service Processor Agent by following the directions above.

To perform a manual installation, follow these steps:

  • Insert the setup media into the system's CD drive or media port, or copy the installation files onto the SVP and put them in an empty directory.
  • If you are aware that the .NET Framework 4.6 is already installed on the system, you may skip this step. Navigate to the Service Processor Agent directory of the installation media and execute the file named dotNetFx46_full_x86_x64.exe. If this program brings up a dialog that gives you choices for "Repair" and "Uninstall", you may click Cancel and skip this step. This program will install the Microsoft .NET Framework 4.6. If this installation fails due to a lack of prerequisite software, see the note above about prerequisite software.
  • Execute the file in the Service Processor Agent directory named SPA.msi by double-clicking it. Follow the prompts on the screen and then Close on the final panel. If this installer presents you with the choices "Repair Service Processor Agent" and "Remove Service Processor Agent", then the Service Processor Agent is already installed and you may chose to cancel or repair the installation.
  • Launch the Service Manager application manually from the Start menu by selecting All Programs/Hitachi Vantara/Service Processor Agent/Service Manager.

The Service Manager icon does not appear in the System Tray

If you have installed the Service Processro Agent and the Service Manager icon does not appear in the System Tray:

  • Verify that the application was installed in the directory specified at the time of installation. The default directories are C:\Program Files\Hitachi Vantara\Service Processor Agent and C:\Program Files (x86)\Hitachi Vantara\Service Processor Agent.
  • Look in the directory C:\Documents and Settings\Administrator\Start Menu\Programs\Startup or C:\Users\Administrator\Start Menu\Programs\Startup and ensure that a shortcut exists in this directory to the file ServiceMgr.exe in the installation directory. If a shortcut does not exist, create one.
  • To start the Service Manager without rebooting, double-click the file ServiceMgr.exe in the installation directory, or from the Start Menu, choose All Programs/Hitachi Vantara/Service Processor Agent/Service Manager. The Service Manager icon should appear in the System Tray.

The Service Manager application does not appear when you double-click the Service Manager icon in the System Tray

It is probably behind the SVP application or another application. Minimize any open applications and you should find the Service Manager application.

The service or services don't start, but no error is displayed or logged in the log files.

Check the system event log (Administrative Tools/Event Viewer). An error may have occurred before the services or service manager could initialize logging.

After re-installing the Service Processor Agent, the Service Manager application does not appear.

Check the system tray for the Service Manager icon. An uninstall does not remove your previously-defined configuration. When the Service Manager starts and finds the configuration file, it does not display the Service Manager application.

When I click a Log button in the Service Manager application, no log window appears.

The log window may already be open and may have been positioned on a larger desktop in a location outside of the visible area on your desktop. Try clicking the Arrange button to reposition it for your desktop.

I installed the Service Processor Agent on a system with open SIMs and the Service Processor Agent does not report them.

The application cannot report SIMs that occurred before it was installed. It does not poll the SVP to determine if there are open SIMs. Rather, it is notified directly by the SVP application when a SIM occurs. Therefore, SIMs that occurred before installation will not be reported.

I see Did not generate ... .dat, but also didn't produce a fail status messages in the back logs.

Data generation relies on certain amounts of the CPU being available, particularly for DCR.dat, DEV,dat, DKC.dat, Einfo.dat, and HDEV.dat generation. As such, a very CPU intensive process like daily disk defragmentation or a CPU intensive virus scans can interfere with the back's ability to generate a complete set of configuration data. In those cases, you should offset either the daily runtime of the other process or the configured data generation time in the Site Manager.

Other Problems?

First, check the Knowledge System. Looking here is the quickest way to find the answer to any problems you may have with the Hitachi Remote Ops Service Processor Agent version D.x.

If you cannot find the answer to your question there, contact GSC with log files and any other relevant information about your problem.

Please do not contact the development group directly.

All Service Processor Agent applications, documentation, and associated files are:


Email Templates

Some customers find it helpful to know the format of email alerts from the application so that they may build intellegent parsing around these notifications into their own email systems. To find the format of a specific type of alert:

  • Select the desired template from the Email Templates section
  • Right-click anywhere within the HTML template
  • Select View Source

Within the source code, any number within parenthesis denotes replacement text of variable value.

Templates are provided for SIM, AutoDump, and Microcode Update alerts. There are a select few scenarios outside of these with which the application will send a simple plain text email notification, if configured to do so. Formats are not provided these simpler messages.

Note: The provided templates are for the default HTML formatting of alerts. If the Send email as plain text only option is selected, the application will send similar messages as plain text that will not follow the provided formatting.

All Service Processor Agent applications, documentation, and associated files are:


This is an automated message generated by the Hitachi Vantara storage system referenced below. Do not reply to this message.

Site ID: | {0}
Site name: | {1}
System type: | {2}
System serial number: | {3}
Log number and index: | {4}
Date and time: | {5}
Reference code: | {6}
Error section: | {7}
Error detail: | {8}
Error location: | {9}
Alert level: | {10}
Status: | {11}

This email is provided as a supplement and is not a replacement for Hitachi Remote Ops reporting to the Hitachi Vantara Support Center call management system. The format of this message may change at any time.


This is an automated message generated by the Hitachi Vantara storage system referenced below. Do not reply to this message.

Site ID: | {0}
Site name: | {1}
System type: | {2}
System serial number: | {3}
Log number and index: | {4}
Date and time: | {5}
Reference code: | {6}
Error section: | {7}
Error detail: | {8}
Error location: | {9}
Alert level: | {10}
Status: | {11}
HDD Serial number: | {12}

This email is provided as a supplement and is not a replacement for Hitachi Remote Ops reporting to the Hitachi Vantara Support Center call management system. The format of this message may change at any time.


This is an automated message generated by the Hitachi Vantara storage system referenced below. Do not reply to this message.

An AutoDump has been requested. The details are below:

Site ID: | {0}
Site name: | {1}
System type: | {2}
System serial number: | {3}
Dump type: | {4}
Date and time: | {5}

This email is provided as a supplement and is not a replacement for Hitachi Remote Ops reporting to the Hitachi Vantara Support Center call management system. The format of this message may change at any time.


This is an automated message generated by the Hitachi Vantara storage system referenced below. Do not reply to this message.

A microcode update has been requested. The details are below:

Site ID: | {0}
Site name: | {1}
System type: | {2}
System serial number: | {3}
DKC Version: | {4}
Start time (UTC): | {5}

This email is provided as a supplement and is not a replacement for Hitachi Remote Ops reporting to the Hitachi Vantara Support Center call management system. The format of this message may change at any time.


This is an automated message generated by the Hitachi Vantara storage system referenced below. Do not reply to this message.

A microcode update has completed. The details are below:

Site ID: | {0}
Site name: | {1}
System type: | {2}
System serial number: | {3}
Version: | {4}

This email is provided as a supplement and is not a replacement for Hitachi Remote Ops reporting to the Hitachi Vantara Support Center call management system. The format of this message may change at any time.


This is an automated message generated by the Hitachi Vantara storage system referenced below. Do not reply to this message.

A microcode update has {0}. Hitachi Vantara Support Center will review this. The details are below:

Site ID: | {1}
Site name: | {2}
System type: | {3}
System serial number: | {4}

This email is provided as a supplement and is not a replacement for Hitachi Remote Ops reporting to the Hitachi Vantara Support Center call management system. The format of this message may change at any time.


Miscellaneous Technical Information

Technical Information

Under normal circumstances, CSRs and site teams should not need the information presented in this section. However under some circumstances the information here could be helpful.

The Services

Normally you will control the services (Site Manager, SVP Agent, and Web Interface) through the Service Processor Agent's Service Manager. However, you can start and stop these service manually either through the Windows Services applet or at a command prompt. The short names of these services are HroSvpAgentSiteManager, HroSvpAgent, and HroSvpAgentWebHost respectively. To stop and start the htfront service manually at a command prompt for example, you can type:

  • net stop HroSvpAgent
  • net start HroSvpAgent

If the Service Manager is open and displaying the General tab while you perform such an operation, you will be able to see the service stop and then start again.

Uninstalling the Services

System services are different than regular Windows programs. Services must be installed before they can be used, and remain installed whether the service is running or not until they are uninstalled.

During setup, the installer will install the services onto the target system. An uninstall will stop and uninstall the services. There should never be any need to manually uninstall the services. But if such a need did arise, they can be uninstalled without running the Add/Remove Programs and completely uninstalling the Hitachi Remote Ops Service Processor Agent software.

In the installation directory is an executable program named UninstSvc.exe. Executing this program will uninstall both system services without removing the Service Processor Agent from the system. If you uninstall the services this way, reinstall them by running the Service Manager. (If the Service Manager is running when you run UninstSvc.exe, you will need to close it and restart it.)

Service Recovery Settings

When the services are installed, the recovery services are set up to restart a service after a one-minute wait period if it should fail for any reason.

Service Manager on SVP Agents

When the Service Processor Agent is installed on a system, the installation program places a shortcut to the Service Manager (the GUI application) in the startup folder for the Administrator. It is important that this shortcut remain in the startup folder — especially on USP and NSC SVP Agents — because the code that catches SIM notifications is actually in the Service Manager application.

If the Service Processor Agent should notify the Center in the event of SIM messages, the Service Manager must be running to catch SIM events.

Data Communication Ports

The Service Processor Agent uses four TCP ports to communicate between Site Managers and SVP Agents. These ports must be open for the services to work properly. The four ports are: 2056, 2057, 2058, and 2059. SVPs configured at the factory should always be pre-configured with these ports open. However even if the ports are not already open, they should not need to be opened manually. Each time the Service Manager (the GUI application) starts up, it will attempt to whitelist the services and applications with the Windows firewall.

On rare occasions, a customer configuration may involve storage subsystems on different subnets or VLANs with switches, routers, or NAT devices separating the subsystems. If the customer firewall policies are very strict, these devices may be set to disallow TCP traffic between the subnets or VLANs destined for certain TCP ports. Or in other words, these devices may be set to allow traffic on a few well-known ports (21, 25, 80 and 8080 for example) and to disallow all other ports.

If it should prove to be impossible to use the default ports, these ports can be changed. In the installation directory (C:\Program Files\Hitachi Vantara\Service Processor Agent), there is a file named RemServer.config. This file is an XML file and the contents should look like the following:

After you change a port setting in this file, if the Service Manager is running, it will notify you that the configuration file has changed and ask if you would like to restart the services. You must make the same changes on all SVP Agents as well as the Site Manager and restart the services on all systems.

GUIDs of Service Processor Agent Versions

GUIDs are provided for the most recent versions of the Service Processor Agent for the purpose of installing a customer supplied SSL certificate for use with the Web Interface, if so desired, as detailed in the AutoDump and Microcode Operations section. GUIDs are only provided for recent versions of the applications. If the version desired is not in this list, please upgrade to the latest release before attempting this operation.

  • D.6: 27650D17-23FB-4549-84C7-414069051402
  • D.5: 6E05714B-2CF9-43E2-BE54-2FBB6A8DD1D1
  • D.4: 33B508C7-88D7-422D-BA06-6550B170D668

Email Templates

Templates for the SIM, AutoDump, and Microcode Update emails sent by the application can be found in the Email Templates section.

All Service Processor Agent applications, documentation, and associated files are:


Hitachi Remote Ops Service Processor Agent - D Series

 Hitachi Remote Ops Service Processor Agent Version D.6 Hitachi Vantara
Installation Notes

This version of the Hitachi Remote Ops Service Processor Agent supports the following Hitachi Vantara storage products, so long as they run the supported Windows OS versions:

Virtual Storage Platform 5500/5500H/5100
Virtual Storage Platform F/G 800/600/400/200/100 (VSP F/G 800/600/400/200/100)
Virtual Storage Platform F/G 1500/1000 (VSP F/G 1500/1000)
Hitachi Unified Storage VM (HUS VM)
Virtual Storage Platform (VSP)

Please Note: Install Hitachi Remote Ops Monitor Agent 8.1 or later to monitor VSP F/G 900/700/370/350/130 systems.

Hitachi Remote Ops Service Processor Agent versions C.E and onward use Microsoft .NET Framework 4.6, which supports the following Windows OS versions:

Windows 10 (including version 1803)
Windows 8.1
Windows 8
Windows 7 SP1
Windows Vista SP2
Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
Windows Server 2012
Windows Server 2008 R2 SP1
Windows Server 2008 SP2

Note 1: This version has no support for Windows XP and Windows Server 2003.

Note 2: Please disable automatic Windows updates on all SVPs running Vista. To do this, go to Control Panel -> Windows Update, click “Change settings”, and choose “Never check for updates” and click OK, and restart the SVP. Otherwise, the installer may freeze (see additional notes below).

See the release notes for important information about bug fixes and new functionality included in the Hitachi Remote Ops Service Processor Agent.
See the help file for detailed instructions for installing and configuring the Hitachi Remote Ops Service Processor Agent.
See the section at the bottom of this document titled Important Notes for installation notes.

Installing Hitachi Remote Ops Service Processor Agent on the VSP 5x00/5x00H, VSP F/G 800/600/400/200/100, VSP F/G 1500/1000, HUS VM, and VSP

You can install the Hitachi Remote Ops Service Processor Agent in one of two ways:

  1. Follow the directions below for installing remotely, or:
  2. Copy the content of the Hitachi Remote Ops Service Processor Agent CD onto a memory stick and follow the directions below for installing from removable media.

Installing from Removable Media

  • Insert the media into the appropriate CD drive or USB port of the SVP.
  • Launch a Remote Desktop session into the SVP.
  • Open Windows Explorer and navigate to the CD or USB drive.
  • Navigate into the Service Processor Agent directory on the drive.
  • Double-click the Service Processor Agent Setup.exe program in that directory.
  • Close or minimize any open windows so that you can see the installation program.
  • Follow the on-screen directions and prompts.

Installing Remotely

  • Insert the CD into the CD-ROM drive of your local system.
  • FTP or otherwise transfer the file HtRemoteInstall.zip to the remote SVP.
  • Launch a Remote Desktop session into the SVP.
  • Navigate to the Service Processor Agent directory.
  • Execute the setup program (Service Processor Agent Setup.exe) by double-clicking on it.
  • Follow the directions presented by the installer and click Continue on the final panel of the installer.
  • Verify that the Service Manager reports the correct version in the lower right-hand section of the panel.
  • Start the appropriate services by clicking the Start buttons.
  • Open the log files to view the startup messages and ensure that the correct version is reported.
  • Click OK to minimize the Service Manager application to the system tray.

Configuration

For detailed step-by-step installation instructions and explanations, see the User Guide in the root directory of the installation media. After installation, the User Guide is available through the Help button in the Hitachi Remote Ops Service Processor Agent Service Manager.

These directions are for the simplest and most common configuration — a single system functioning as both a Service Processor Agent and Site Manager. For other configurations, see the User Guide.

  • Close the installation program and close or minimize any other open windows (other than the Hitachi Remote Ops Service Processor Agent Service Manager).
  • Click on the Site tab of the Service Manager and enter the site ID (which is required) and optionally the customer name.
  • Click the Center tab and edit the contact methods list.
  • Click the Subsystems tab and validate the first entry in the list as the local subsystem.
  • Click the General tab and click the Site Manager Log and Agent Log buttons to view the log files (which should be empty at this point). Click the button labeled Arrange and leave the log windows open at this time.
  • On the Service Manager window, click the Apply button. Correct any validation problems pointed out by the Service Manager. (Note: if you see a message indicating that the Service Processor Agent could not update the configuration on the standby SVP, then you are installing the Hitachi Remote Ops Service Processor Agent on a system equipped with dual SVPs. Take this message as a reminder to install on the standby SVP as well.)
  • Click Yes to the prompt to start the services.
  • Watch the logs for a minute or so to look for any errors or unusual messages.
  • On the Utilities tab, click the Transfer Now to test a call.
  • Watch the logs until the call completes to look for any errors or unusual messages.
  • Close the log windows.
  • Click OK on the Service Manager to minimize the application to the system tray.

Important Notes

[1] Full Hitachi Remote Ops Service Processor Agent functionality requires use of the following TCP ports:

  • 2056 and 2058 for communication from each subsystem to the Site Manager
  • 2057 and 2059 for communication from the Site Manager to each subsystem
  • 443 for data transfer from the Site Manager to the Hitachi Remote Ops Center
  • 4431 or whichever port is configured during installation to host the Web Interface on the Site Manager

[2] Version C.D and higher uses the .NET Framework 4.6. This is a change from versions prior to C.D. The installer program should automatically install .NET 4.6 during the installation process. If for some reason the installation fails, you can manually install .NET Framework 4.6. To do so, follow the directions in the next note. Be aware that to install the .NET Framework 4.6, you may have to update the Windows installer to the latest version. The latest version of the Windows Installer is on the installation media in the "\Prerequisites\Windows Installer 4.5\" folder.

[3] To deploy at a site with multiple subsystems, we recommend you install the latest version on all systems. Moreover, if the site has one or more VSP (or newer) storage systems or any systems at version C.1 or higher, it is required to install this version of the Hitachi Remote Ops Service Processor Agent on the Site Manager (front) system to correctly transfer all relevant data including CSV data to the Hitachi Remote Oops.

[4] Normally it is not necessary to uninstall previous versions of the Hitachi Remote Ops Service Processor Agent to upgrade to the latest version. The exception to this is if you need to perform a manual installation (using SPA.msi instead of Service Processor Agent Setup.exe). In this case, you should first go into the Control Panel and remove all prior version of before proceeding with a manual installation.

[5] Service Manager configuration settings from the prior version are always preserved during an upgrade.

  • Vista SVPs: If automatic Windows Updates are enabled (despite the recommendation of Hitachi Vantara), and if Windows Update is not able to connect to the Windows Update servers, the installation of Microsoft Visual Studio 2015 C++ Redistributable may hang. If after several minutes the installation of the redistributable does not complete, please try the following:
    1. Uninstall Hitachi Remote Ops Service Processor Agent Bootstrapper through Control Panel -> Programs and Features
    2. Uninstall Visual Studio 2015 C++ Redistributable (x86) through Control Panel -> Programs and Features
    3. Disable Windows Update: Go to Control Panel -> Windows Update, click “Change settings”, and choose “Never check for updates” and click OK.
    4. Restart the SVP.
    5. Try installing the SVP Agent again.

[7] Versions C.7 overwrites previous versions of the database file HiTrackDb.sdf to correct a deficiency in it. This overwrite resets the Web Interface configuration, including the user information.

[8] Versions C.6 and higher enable a Web Interface for AutoDumps requests by default upon installation. The web application opens the port configured during installation and creates a windows firewall rule to allow incoming traffic. The Web Interface can be disabled in the service manager, deleting the created firewall rule and closing the opened port. Reference the help file to do so.

[9] The Web Interface is supported on Microsoft Internet Explorer 9 or above, Google Chrome, and Mozilla Firefox. It also displays on Internet Explorer 8, but with a diminished GUI experience and possible loss of datepicker functions for the Log page.

[10] If the Setup program fails to install the Hitachi Remote Ops Service Processor Agent properly, follow the steps below to install the Hitachi Remote Ops Service Processor Agent manually:

  • Install the .NET Framework 4.6: Navigate to the Service Processor Agent directory of the installation media and execute the file named dotNetFx46_Full_x86_x64.exe. If this program brings up a dialog that gives you choices for "Repair" and "Uninstall", you may click Cancel and skip the rest of this step because the .NET Framework 4.6 is already installed on the system.

    On some platforms you may receive a message that the Windows Installer needs to be upgraded to install .NET 4.6. if you receive this message, current versions of the Windows Installer are in the "\Prerequisites\Windows Installer 4.5\" folder on the installation medium. Identify the package for the target system by the file names and execute the appropriate package to update the Windows Installer.

  • Notes: It is not normally necessary to uninstall prior versions in order to upgrade to the latest version. The configuration settings from the prior version will be retained after the upgrade.

  • Install the Hitachi Remote Ops Service Processor Agent: Navigate to the \Service Processor Agent folder of the installation medium, right-click the file named Service Processor Agent Setup.exe and choose “Run as administrator”. (Note: on Windows XP systems you can just execute the program by double-clicking Service Processor Agent Setup.exe.) Follow the directions in the installation program to install the Service Processor Agent. When you click “Continue” on the final panel of the installation program, the installer will launch the Service Manager application.

  • Direct manual installation: If the above installation step fails for any reason, you may need install the HTA.msi package directly: to do this:

    1. Go to the system Control Panel and uninstall any prior versions of the Hitachi Remote Ops Service Processor Agent.

    2. Execute the file in the Service Processor Agent directory named SPA.msi by double-clicking it. (Note you may need to confirm a UAC challenge.) Follow the prompts on the screen to click Next twice and then Close on the final panel. If this installer presents you with the choices "Repair Service Processor Agent" and "Remove Service Processor Agent", that means the application is already installed and you may chose to cancel or repair the installation instead.

    3. When you install the agent this way, you will need to launch the Service Manager application manually from the Start menu by selecting All Programs/Hitachi Vantara/Hitaci Remote Ops Service Processor Agent/Service Manager.

Hitachi Remote Ops Service Processor Agent applications, this documentation, and all associated files and documents are:

Copyright © 1995-2021 Hitachi Vantara
All rights reserved.


Release Notes

Hitachi Remote Ops Service Processor Agent
Release Notes Hitachi Vantara

This document describes enhancements and bug fixes to the Hitachi Remote Ops Service Processor Agent through version D.6.

D.6 Feb 23, 2021

Bugs Fixed in this Version

  • [430] Version D.5 fails to uninstall properly on standby SVPs.
  • [429] System updates in version D.5 fail to invoke an update on VSP F/G 200/400/600/800 systems.
  • [428] System updates in version D.5 may incorrectly display any occurring errors from failures during the precheck or progress check of the update.
  • [427] System updates may wait a while before notifying Hitachi Vantara of the updates completion.
  • [426] System updates may fail to acknowledge or process cancellation requests.
  • [425] The automatic daily call that should occur after a failed or successful system update may fail to occur.
  • [424] Site Manager may fail to fetch SIM from a system if the Site Manager cannot query the microcode version of the system.
  • [423] CSV configuration information may fail to generate on VSP F/G 200/400/600/800 systems.
  • [422] Dumps in version D.5 may fail to generate on VSP 5500/5500H/5100 systems.
  • [421] A system may fail to clean-up accumulated performance data.

Changes and Enhancements

  • [420] Outstanding SIMs will not be deleted if they are older than 3 days. All outstanding SIMs will automatically transfer to Hitachi Vantara upon detection.
  • [419] Syslog auditing of Web Interface and Hitachi Remote Ops activity is supported. This behavior can be configured through the Advanced tab of the Service Manager
D.5 Dec 18, 2020

Bugs Fixed in this Version

  • [418] SIM notification fails if a prior SIM has been received by the Site Manager from a system no longer registered in its subsystems list.
  • [417] SIM notification failure may occur during a flood of SIMs if new SIMs are being written at the exact same time as that the Site Manager is being notified of an outstanding SIM..
  • [416] SVP Agent may unexpectedly stop on VSP F/G 200/400/600/800 systems running versions D.3 or D.4 of the application.
  • [415] Remote microcode update fails on VSP F/G 200/400/600/800 systems when updating to microcode at DKC 83-05-35-40/00 or higher.
  • [414] Site Manager doesn't resume remote microcode update processing on VSP F/G 200/400/600/800 systems that are also functioning as a Site Manager if the Site Manager service has been interrupted during the application of microcode.
  • [413] Dumps that fail and return failure return codes on VSP G1500/G1000/F1500, VSP F/G 200/400/600/800, and VSP 5500/5500H/5100 systems fail to log the failure codes and fail to signal to the Site Manager on failure that the attempt to generate a dump has ended.
  • [412] Queued dump requests are not attempted if the Site Manager has been restarted.
  • [411] Acknowledged microcode updates fail to start as scheduled if the Site Manager has been restarted.
  • [410] Parity group information gathered from VSP 5500/5500H/5100 systems is incomplete.
  • [409] During daily call, if the Site Manager encounters a system that has not checked in with it, the Site Manager will not fetch fresh configuration data from subsequent systems in its subsystems list.
  • [408] The Service Manager will inaccurately alert about failing to start the Site Manager or SVP Agent services if either of them is in a start-pending state.
  • [407] The Web Interface does not automatically start when enabled if it was recently disabled.
  • [406] On Dual SVP configurations, changes to a primary's configuration is not sent to the standby SVP in certain scenarios.
  • [405] On Dual SVP configurations, the SVP Agents running on the primary and standby SVPs are unable to determine the IP address for one another if the configured IP addresses do not follow the maintenance manual recommendations. The Service Manager has been updated to allow the IP address of both the primary and standby SVPs to be explicitly configured.
  • [404] For dedicated Site Managers that aren't running on RAID enterprise storage, only a part of their logs is collected during daily call.
  • [403] IP address information within gathered HCSC license data is not masked even if the Site Manager is configured to Hide IP Addresses.
  • [402] Service Manager alerts about failures to send primary SVP settings to standby SVPs on systems that are not using a Dual SVP configuration.
  • [401] Dumps that fail to transfer on the first pass are prematurely deleted an hour before the 8-hour dump transfer timeout.

Changes and Enhancements

  • [400] The Microsoft Visual Studio C++ Redistributable is no longer a prerequisite component of this application and is no longer installed before installing the application.
  • [399] Support for USP V and USP VM devices has been dropped.
  • [398] New FTP and FTPS transport destinations cannot be defined. Use of FTP and FTPS for transport is being deprecated.
  • [397] New installations will automatically configure default HTTPS destinations for transport and polling.
  • [396] Upgraded installations will automatically configure any default HTTPS destinations for transport and polling that are missing.
  • [395] The Web Interface is now opt-in. This feature will be disabled by default on new installations.
  • [394] The sessions timeout for the Web Interface has been decreased to 15 minutes.
  • [393] The Enable Dump Polling setting has been changed to the Enable Remote Ops requests setting and encompasses a wider array of remote maintenance operations beyond AutoDump collection like remotely triggered daily call, SVP reboots, and software updates of the Service Processor Agent. This setting is enabled by default and opt-out for new installations.
  • [392] Support has been added for remote software updates of the Hitachi Remote Ops Service Processor Agent when running versions D.5 or higher of the application. This feature can be controlled by the Enable Remote Ops requests setting.
  • [391] Support has been added for remote reboots of the SVP when running versions D.5 or higher of the application. This feature can be controlled by the Enable Remote Ops requests setting.
  • [390] Support has been added for ORM log collection on VSP 5500/5500H/5100 systems.
  • [389] Support has been added for Limited AutoDump collection on VSP 5500/5500H/5100 systems running DKC code at or higher than 90-06-00-00/00.
  • [388] New Service Monitor service monitors and restarts the Site Manager and SVP Agent services if either has not been intentionally stopped.
  • [387] Remote microcode updates will trigger daily call after completion.
  • [386] Dump transfer progress is now logged in the Site Manager logs.
D.4 Nov 27, 2019

Bugs Fixed in this Version

  • [385] FrontSvc.exe may be falsely flagged as a virus by various anti-virus suites.
D.3 Oct 02, 2019

Bugs Fixed in this Version

  • [362] The Site Manager attempts to transport already transported and no longer existent SIMs.
  • [363] The Site Manager drops a back's explicitly specified registration address.
  • [364] Adding an FTP contact method attempted to add a dial-up contact method.
  • [365] FFI parts file transfers were not logged in the transport logs.
  • [366] IP addresses in AllConf01.csv were not masked if configured to do so for USP V and USP VM. This release addresses this issue and masks those IP addresses.
  • [367] Remote microcode upgrade requests are lost upon stop of the front service.
  • [368] Cancellation of remote microcode upgrade requests do not always signal an acknowledgement or failure of the cancellation.
  • [369] Remoting failures between the front and back hang communication.
  • [370] Remote microcode updates on VSP Fx00/Gx00 arrays prematurely signals a successful upgrade while the firmware update process is reading the configuration.

Changes and Enhancements

  • [371] Rebrands to Hitachi Remote Ops Service Processor Agent. This affects install and startup menu locations.
  • [372] Adds support for VSP 5x00/5x00H systems.
  • [373] Supports remotely triggered transport of configuration and performance data.
  • [374] Supports remotely triggered disabling of the Service Processor Agent and Site Manager.
  • [375] OSS version information is collected on VSP Gx00 systems.
  • [376] WMIC hard disk partition capacity information is collected.
  • [377] Service Manager denotes between services in a stopped and disabled state.
  • [378] SIM processing and transfer happens completely concurrent to any daily and dump transfer occurring at the same time.
  • [379] Changes to SIM reporting configuration are logged.
  • [380] CPU utilization is logged by a back before it prepares for daily call.
  • [381] Cancellation requests for remote microcode updates are checked for and applied, if applicable, immediately upon receipt.
  • [382] Cancellation requests for remote microcode updates queue up for later checking if the remote Site Manager or Service Processor Agent are busy and can't be immediately checked for matching requests.
  • [383] Successful completion of a microcode update will automatically cancel any pending requests there were made before the application of new code.
  • [384] Expands logging and polling responses for SIMs and remote operations.
D.2 April 8, 2019

Bugs Fixed in this Version

  • [354] SIMs do not transport in version D.1 if the Enable SIM triggered AutoDump transfer option is unchecked.
  • [355] Dumps that successfully transfer to Hitachi Vantara may retry to transfer the file and fail to send a transfer completion response.
  • [356] On backs configured with an invalid Site Manager, dumps requested through the Service Manager fail to generate.
  • [357] Remote microcode updates fail to send responses about success and completion when the front loses connectivity to the back.
  • [358] Configured SOCKS proxies are ignored during HTTPS transfer.

Changes and Enhancements

  • [359] Scheduling of remote microcode updates is now based on a server supplied time.
  • [360] Hi-Track installs in the Hitachi Vantara subdirectory of the Program Files directory instead of Hitachi Data Systems subdirectory.
  • [361] Hi-Track's start menu directory changed to Hitachi Vantara instead of Hitachi Data Systems.
D.1 Dec 07, 2018

Bugs Fixed in this Version

  • [334] The Site Manager fetches the latest dump from a back, without verifying that the retrieved dump matches the requested dump.
  • [335] During dumps or remote microcode updates, the Site Manager incorrectly logs that it cannot connect to a connected back.
  • [336] Dump polling may send an erroneous Notified status before sending the correct Busy or Skipped status.
  • [337] Dumps will continually reattempt to transfer after a successful transfer.
  • [338] Remote microcode updates requests received at the same time as a dump request may fail to notify the back.
  • [339] SIMs skip checking AutoDump triggers when occurring in quick succession.
  • [340] A security issue related to LDAP authentication was resolved.
  • [341] The HTA_DumpInterfaceReset.exe file has been removed. This file can sometimes cause a false positive anti-virus indication.
  • [342] Out-of-date SVPMON performance data files persist from prior versions.

Changes and Enhancements

  • [343] Upgrades Microsoft SQL Server Compact Edition 4.0 to Microsoft SQL Server Compact Edition 4.0 SP1.
  • [344] Site Managers can now process multiple dumps simultaneously, with a limit of one dump per unique system being allowed during a single dump sequence.
  • [345] Site Managers will attempt to re-connect with all backs before all daily call, dump, and remote microcode update attempts.
  • [346] Adds a dump polling response for connect attempt failures during wait for dump.
  • [347] Adds a dump polling response for dumps that don’t complete within the allowed time limit yet have not hit the connection failure limit.
  • [348] IP Address information will be masked within an array’s back logs, CSV files, and Hi-Track.dat file, if the Site Manager it belongs to is configured to hide IP addresses.
  • [349] IP Address information will be masked in the Site Manager’s logs if the Site Manager is configured to hide IP addresses.
  • [350] IP Address information will be masked in the Service Manager’s logs if the Site Manager responsible for the device running Hi-Track is configured to hide IP addresses.
  • [351] Updates references to RAID 800 and HM 800 to their marketing names.
  • [352] Updates all UTC time references to GMT time references for consistency.
  • [353] Adds the option to enable/disable SSL certificate validation for email notifications that use SSL.
D.0 June 26, 2018

Bugs Fixed in this Version

  • [306] Some systems were not included in dump and/or microcode polling that were capable of centralized dumps or remote microcode updates.
  • [307] Remote microcode updates would never start for any Site Manager that had multiple systems reporting to it.
  • [308] If the system was already busy with a dump or a remote microcode update, and another remote microcode update was requested, the error message would incorrectly indicate that the system was busy sending configuration data to Hitachi Vantara.
  • [309] If a microcode upgrade timed out, the Site Manager would send an error message for all systems reporting to it, instead of just the system where the remote microcode upgrade failed.
  • [310] The new transport destinations usdenhtinet01.hds.com and usdenhtinet02.hds.com were mistakenly added to Site Managers running on systems with Windows Vista or 2008 installed, which do not support TLS 1.2.
  • [311] A "Failed" status message would be incorrectly sent to Hitachi Vantara after the first and second microcode retry. The message will now only be sent after the third and final retry.
  • [312] The Site Manager would, in some cases, stop monitoring the progress of an update on a system.
  • [313] Disabling configuration data transfer to Hitachi Vantara did not disable performance data generation and transfer.
  • [314] Disabling configuration data transfer to Hitachi Vantara resulted in unnecessary log messages about the disabled status.
  • [315] The version of the SVP Agent running on each subsystem was not transmitted to Hitachi Vantara in the dump/microcode polling.
  • [316] Incorrect log messages would be generated for any system that was not reachable from a Site Manager performing a microcode upgrade on any system.
  • [317] Remote microcode updates would never start for a system that had an extended period of no network connectivity.
  • [318] If an error occurred transferring dump files to the Site Manager from the system, the corrupted files would be transferred to Hitachi Vantara. The Site Manager will now retry the file transfer for a limited number of attempts.
  • [319] It was possible to add the same IP address twice to the system list.
  • [320] VSP G/F 1500/1000 HDP compression data and some VSP HDP data was not generated or transferred to Hitachi Vantara.
  • [321] The format of the cache performance data did not indicate the overall performance statistics properly.
  • [322] Remote microcode updates that had stalled were not aborted.
  • [323] In some cases, an error connecting to any system from the Site Manager would result in the Site Manager being unable to perform dump and microcode upgrade polling to Hitachi Vantara.

Changes and Enhancements

  • [323] SSL certificate validation will now be automatically enabled on upgrading to D.0. If the customer firewall will not permit SSL certificate validation and/or is configured to connect to the IP address of the transfer server rather than the domain name, SSL certificate validation will need to be manually disabled for each transport method as well as for dump/microcode polling. However, this is not recommended as SSL certificate validation is an important security measure that prevents impersonation of Hitachi Vantara web servers.
  • [324] The distinction between a daily and a weekly call home to Hitachi Vantara has been removed since configuration data is now always transferred on a call home.
  • [325] It is now possible to cancel microcode requests, as long as the update application process has not been started.
  • [326] Certain outdated or corrupted performance data files will now automatically be deleted.
  • [327] A maximum of 5 SIM-triggered auto dumps will be generated during a calendar day.
  • [328] The MiscFront.dat data, containing additional data from the Site Manager, will now be transported with every subsystem connected to the Site Manager rather than just one of them.
  • [329] The Site Manager will now collect the time zone information from the system it is installed on and include it in MiscFront.dat.
  • [330] The Visual Studio 2015 C++ Redistributable is now included instead of the 2012 version.
  • [331] The integrated nsoftware IPWorks! components have been upgraded from version 9.0 (SSL) to 2016 (regular).
  • [332] Information on whether the SVP is in modify mode is now printed to the SVP Agent logs before a remote microcode upgrade.
  • [333] An option to disable polling to Hitachi Vantara for dump requests and microcode updates was added to the Hi-Track Dump Interface accessible with a web browser.
C.F February 1, 2018

Bugs Fixed in this Version

  • [266] Extra "Periodic performance stat collection restarted" messages were included in the logs.
  • [267] The cache rate in the LDEV.csv performance data was incorrect. Version C.F fixes this with the correct data in LDEV2.csv.
  • [268] Some old performance data was not clearing out properly.
  • [269] The automated cleanup of performance data was running every time performance data was generated.
  • [270] A memory leak could occur when generating the configuration data for a daily transport.
  • [271] If transfer of configuration data was disabled, the Transfer Now button would still transport configuration data to Hitachi Vantara.
  • [272] If transfer of configuration data was disabled, an error message would appear in the logs repeatedly.
  • [273] If the transfer of performance data from the SVP to a Site Manager failed, the Site Manager would skip transfer of any configuration data from another system.
  • [274] The domain proxy name would not always be used when dump polling.
  • [275] Outdated performance data and some dump files would be kept indefinitely until they could successfully be transferred to Hitachi Vantara.
  • [276] If the PersistentData.xml file was corrupted, performance data would not properly generate.
  • [277] There was a rare issue where HDP configuration data would not be properly generated if the SVP and DKC versions did not match.
  • [278] Duplicate messages about the SVP Agent starting would sometimes appear in logs.
  • [279] For HTTPS contact methods, the domain proxy field would always be enabled even when no proxy was configured.
  • [280] A SVP Agent doing a daily transport and handling a SIM at the same time might result in the SIM data transport failing.
  • [281] Systems with serial numbers starting with one or more zeros (including after the 4 or 2 prefix on VSP Gx00/Fx00 or HUS VM systems) were not properly supported. Version C.F fixes this bug, after it was partially fixed in C.E.
  • [282] Dump file transports over 2 GB would fail. The transport destinations now enforce the size limit, which currently is around 4.29 GB.
  • [283] The date widget in the web AutoDump interface would sometimes be cut off in Google Chrome.
  • [284] Hi-Track.dat would not generate properly on some systems. Version C.F mitigates this bug by generating a version of the file with some data, but a fix to the Windows Registry must be applied to completely resolve this rare issue.
  • [285] If one SVP connected to a Site Manager was nonresponsive, dump polling would not work for any SVP at that Site Manager.
  • [286] Only the first 100 KB of the Site Manager logs would be transported to Hitachi Vantara if the Site Manager was on a customer-supplied platform. Version C.F fixes this bug by increasing the limit to 500 KB.
  • [287] Proxy and proxy interface IPs were not obscured from the logs when the "Hide IP addresses" option was selected.

Changes and Enhancements

  • [288] For VSP G1x00/F1500, VSP Gx00/Fx00, HUS VM, and VSP, remote microcode updates are now supported. The following microcode versions must already be installed to perform an upgrade: VSP G1x00/F1500: SVOS 7.3.1, 80-06-02-00/00-M132 or greater; VSP Gx00/Fx00: supported with a future release of microcode; HUS VM: 73-03-58-00/00-M082 or greater; VSP: 70-06-53-00/00-M281 or greater.
  • [289] Performance data for VSP Gx00/Fx00 will now be generated and transported to Hitachi Vantara.
  • [290] Dump polling now uses a different mechanism that will improve tracking of dumps and allow for polling for remote microcode updates.
  • [291] Support for dial-up transport has been removed. Data must now be transferred to Hitachi Vantara over FTP, FTPS, or HTTPS.
  • [292] For VSP Gx00/Fx00, if the option to send an email for SIM errors is enabled, an email will be also be sent for GUM communication failures
  • [293] Support for the new transport destinations usdenhtinet01.hds.com and usdenhtinet02.hds.com have been added. These new destinations require support for TLS 1.2, which is not supported on Windows Vista and must be manually enabled on some Windows 7 systems.
  • [294] The SVP Agent has been rebranded as a Hitachi Vantara application, to reflect the company name change.
  • [295] The default dump and microcode update polling interval has been changed from every 180 seconds to every 300 seconds. Any value below 300 seconds will be ignored, and the site manager will poll every 300 seconds in this scenario.
  • [296] All numerical references to subsystems now display the number in decimal rather than hexadecimal format.
  • [297] The maximum daily log file size has increased to 10 MB.
  • [298] The native .NET compression API is now used to handle ZIP files.
  • [299] Dump polling processing will now time out after 10 minutes instead of 30 minutes.
  • [300] For VSP Gx00/Fx00, the 1c0000 reference code will now generate an AutoDump.
  • [301] The Service Provider field has been moved to the Site tab, and the Notification tab has been reorganized.
  • [302] The two-hour timeout for requesting dumps has been removed. Dump requests received while a dump is generating will still be ignored.
  • [303] Transport method and dump proxy settings will now use the same settings for each type of transport (FTP(S) and HTTP).
  • [304] The reference code is added to the logs when transporting SIM data.
  • [305] A new option has been added to send an email when a SVP connected to a Site Manager does not respond to communication after an hour.
C.E Mar 15, 2017

Bug Fixes

  • [237] Some dump polling failures that occur after dump polling successes go unlogged. Version C.E fixes this.
  • [238] MiscFront.dat would always identify the first storage system as the site manager in the case that the site manager is a customer-supplied platform. Version C.E fixes this error.
  • [239] An error occurred when an administrator on the dump web interface tried to delete itself. Version C.E no longer allows for an administrator to do this.
  • [240] Rebooting the SVP during a dump request would result in a dump requested soon thereafter failing. Version C.E fixes this error.
  • [241] Performance data generation would sometime stop if the data files were corrupted. Version C.E fixes this bug.
  • [242] FFI parts files older than 72 hours were not actually deleted. Version C.E fixes this bug.
  • [243] Systems with serial numbers starting with one or more zeros (including after the 4 or 2 prefix on VSP Gx00/Fx00 or HUS VM systems) are properly supported.
  • [244] Systems with Windows 10 installed are now properly identified as such in Hi-Track data.
  • [245] Systems that cannot support dump requests are no longer included in dump polling to HDS. This would include those with a SVP Agent version below C.7, or USP or NSC systems.
  • [246] The Help button in the Service Manager did not work. Version C.E fixes this bug.
  • [247] The log viewer window would sometimes stop responding. Version C.E fixes this bug.
  • [248] A rare issue would sometimes occur where a daily transport and a SIM would conflict. Version C.E fixes this bug.
  • [249] The batch dump report API function would fail if a FFI dump had ever been generated on the system. Version C.E fixes this bug.
  • [250] After changing the dump polling proxy settings to or from SOCKS, or after receiving a dump request under SOCKS, the service manager would poll twice under both SOCKS and non-SOCKS proxy settings. Version C.E fixes this bug.
  • [251] Centralized dump requests submitted with any blank fields would fail if the service manager used a SOCKS proxy. Version C.E fixes this bug.

Changes

  • [252] Compression pool and virtual volume data is transported on VSP Gx00/Fx00 and G1x00/F1500 systems if the microcode installed is capable of generating this data.
  • [253] The installed version of Microsoft IIS Express has been upgraded from 7.5 to 8.0. Customers who have IIS Express 10.0 installed will also be able to use it with the SVP Agent.
  • [254] The self-signed SSL certificate for the web dump interface has been upgraded to support SHA-256.
  • [255] A new listing of all the dump files that have been transferred to HDS has been added. It can be accessed by clicking "View Transported Dump Files" on the AutoDumps tab.
  • [256] A new option to send an email whenever a dump request is received has been added under the Notifications tab.
  • [257] A new option to send emails as plain text only has been added to the Notifications tab.
  • [258] A new option to disable transport of Hi-Track data in the regular "call-home" process has been added. It is highly recommended that this data be allowed to transfer to HDS (and that this option is not used) for improved customer support.
  • [259] The default dump polling interval has been changed from every 120 seconds to every 180 seconds. Any value below 180 seconds will be ignored, and the site manager will poll every 180 seconds in this scenario.
  • [260] The serial number of the affected system is now included in a SIM notification email.
  • [261] SIMs generated during a daily or weekly transport will now be transported immediately to HDS rather than at the end of the transport.
  • [262] A storage system that can no longer initiate communication with the site manager will no longer transport Hi-Track environment data to HDS. A healthcheck case will be opened on Siebel so that the connection issue can be investigated.
  • [263] The integrated nsoftware IPWorks! SSL components have been upgraded from version 8.0 to 9.0.
  • [264] The "Trigger Dump For All Subsystems" button was removed from the Service Manager GUI.
  • [265] Logging for AutoDump requests and polling has been improved.
C.D Mar 01, 2016

Bug Fixes

  • [228] The dump lockout prevented dumps from triggering more than every 12 hours instead of 2 hours. Version C.D fixes this.
  • [229] The External LDEVs information (ExtLDEV2.dat) collected on VSP Gx00 systems is incomplete. Version C.D fixes this.

Changes

  • [230] Collects the parts information from FFI dump files for the VSP systems running 70-06-22/01 microcode or higher.
  • [231] Collects the parts information from FFI dump files for the HUS VM (HM700) systems running 73-03-40/00 microcode or higher.
  • [232] Collects the parts information from FFI dump files for the HUS VM (HM710) systems running 75-03-40/00 microcode or higher.
  • [233] Adds the options to skip the transfer of Config.zip.
  • [234] Adds support for TLS 1.1 and TLS 1.2 for the Dump Interface on applicable OS levels.
  • [235] Adds support for TLS 1.1 and TLS 1.2 for dump polling on applicable OS levels.
  • [236] Adds support for TLS 1.1 and TLS 1.2 for HTTPS and FTPS transfer on applicable OS levels.
C.C Nov 21, 2015

Bug Fixes

  • [214] DAT file retries don't generate success or failure messages. Version C.C fixes this.
  • [215] FMD dump types on VSP G1000s are broken. Version C.C fixes this.
  • [216] HUS VM systems of type HM710 don't check for SIM triggered AutoDumps. Version C.C fixes this.
  • [217] HTTP Contact Methods did not register changes to the Domain Authentication option or the value of the Domain if those were the only configuration options changed in the contact method. Version C.C fixes.
  • [218] Installation on a non-English language Windows OS fails when the installer configures the Dump Interface. Version C.C fixes.

Changes

  • [219] Added support for VSP Gx00 High model type (VSP G800).
  • [220] Added support for SOCKS HTTP proxies for transport methods and dump polling.
  • [221] Added System Memory Information collection for the VSP Gx00 system type.
  • [222] Added the Monitor dump type for the VSP G1000 system type.
  • [223] Added the FMD and Config dump types for the VSP Gx00 system type.
  • [224] Collects ORM information from VSP G1000 systems running V03 microcode or higher.
  • [225] Collects the parts information from FFI dump files for the VSP G1000 systems running V03 microcode or higher.
  • [226] Collects performance data from VSP, HUS VM, and VSP G1000 system types.
  • [227] Hi-Track checks the VSP Gx00 identifying registry key on every BackSvc start-up instead of checking only once at install.
C.B May 07, 2015

Bug Fixes

  • [213] The Hi-Track Site Manager does not properly carry over the proxy type configuration when upgraded to C.A.. As a result, Hi-Track does not correctly recognize the proxy configuration or changes made to it. Version C.B fixes this.
C.A April 22, 2015

Bug Fixes

  • [210] The Hi-Track Dump Interface runs when it shouldn't on systems configured only as a back. Version C.A fixes this.

Changes

  • [211] Adds support for the VSP Gx00.
  • [212] Collects Hi-Track configuration of agents configured only as a front.
C.9 March 23, 2015

Bug Fixes

  • [199] AutoDump Polling Configuration Window Hangs on Close: The AutoDump Polling Configuration sub-window of the Hi-Track Service Manager may hang for a noticeable amount of time if the Apply or Close buttons are pressed immediately after the Test button has been pressed. Version C.9 fixes this.
  • [200] Selected checkboxes reset after a few seconds on the AutoDump Web Interface's Home page. Version C.9 fixes this.
  • [201] The OK button doesn't appear after adding or editing a Subsystem's IPv4 or IPv6 Registration Address. Version C.9 fixes this.
  • [202] A changed IPv4 or IPv6 Registration Address requires a manual restart of the SVP Agent service in order to update the Site Manager with the changed address if the SVP Agent service is running when the change is made and already registered and connected to the Site Manager. Version C.9 fixes this.
  • [203] FrontSvc.ConnectToBack error messages spam the Site Manager logs upon continued failure. Version C.9 fixes this.
  • [204] FrontSvc.ConnectToBack exceptions hang dump and file transfers. Version C.9 fixes this.
  • [205] The Resend SIMs option resends SIMs every other day rather than every day. Version C.9 fixes this defect.

Changes

  • [206] Adds support for HUS VMs configured with a Dense-60 drive boxes.
  • [207] Added a Validate SSL Certificate option for polling any configured servers for dump polling. This option is disabled by default and can be found in the Hi-Track Service Manager's AutoDump Polling Configuration sub-window.
  • [208] Added an Interface Configuration dialog under the Hi-Track Service Manager's AutoDumps tab from which the admin password for the AutoDump Web Interface can be reset to the default value.
  • [209] Collects Protection Level Information on VSPs.
C.8 Nov 24, 2014

Bug Fixes

  • [183] SIM report failure: Hi-Track can fail to report SIMs under these specific conditions. 1) Both dialup and IP transport methods are configured. 2) The IP transport methods configured do not work. 3) The dialup method is listed at 1st (that is at the top of) in the contact methods list. Version C.8 fixes this.
  • [184] VSP G1000 SVP Agent unexpected failure: The Hi-Track SVP Agent can unexpectedly shutdown and require restart on VSP G1000 systems on which 4 or more DKC batteries are configured. Version C.8 fixes this defect.
  • [185] VSP G1000 BatteryLifeEach.Dat files are incomplete: The BatteryLifeEach.dat generated by Hi-Track SVP Agent on VSP G1000 systems is incomplete. Version C.8 fixes this.
  • [186] SVP Agent fails to read microcode levels upon start-up. Version C.8 fixes this.
  • [187] Unread microcode level restricts DAT File Generation for DAT files whose API is microcode level dependent. Version C.8 fixes this.
  • [188] FTPS contact methods fail if the Transfer to HDS Only option is configured for it. Version C.8 fixes this.
  • [189] Site Managers may register an incorrect IP address for SVP Agents on a different network if the IP address of the Site Manager starts with a different octet than the SVP Agent. This is not guaranteed to happen but may occur depending on the ordering of the SVP Agent's assigned IP addresses. Version C.8 fixes this.
  • [190] The SVP Agent service runs when it shouldn't on non-subsystem machines. The service starts upon restart and cannot be stopped via the Service Manager because the UI control is not enabled. Version C.8 fixes this.
  • [214] SIM triggered AutoDumps don't label the generated AutoDump with the triggering SIM code. Version C.8 fixes this.

Changes

  • [191] VSP G1000 does not generate BatteryLife.dat due to dropped support.
  • [192] SVP Agents may explicitly specify the IP address used to register with a Site Manager if the SVP Agent is not also a Site Manager.
  • [193] Added IPv6 address support. Site Managers can be registered with IPv6 from an SVP Agent exactly as an IPv4 address would be registered. SVP Agents can define IPv6 addresses to use for registration from the Subsystems tab of the Hi-Track Service Manager if the SVP Agent is not also functioning as a Site Manager.
  • [194] SIM triggered AutoDumps are now appended with _auto_SIMREF where SIMREF is the SIM reference that triggered the dump.
  • [195] Added support for appending SR numbers to polling triggered AutoDumps.
  • [196] Enhanced dump polling to better detail what stage of the dump process the Site Manager is on.
  • [197] The Dump Interface now supports batched request.
  • [198] Hi-Track is now FIPSs compliant and will run as intended on Windows operating systems with that FIPS compliance enabled.
C.7 April 21, 2014

Bug Fixes

  • [172] IOException hangs Hi-Track transfer: An IOException during a transfer would cause the transfer process to hang until the Site Manager was restarted. Version C.7 fixes this.
  • [173] SIM transport fails with incorrect contact method: The Site Manager may fail to transport a SIM on subsequent transfer attempts if the previous attempt failed due to an incorrectly setup contact method. Version C.7 fixes this.
  • [174] HUS VM unable to determine the system type after install: The API used to generate BatteryLife.dat is not supported on the HUS VM systems. Version C.7 eliminates BatteryLife.dat generation for HUS VM systems.
  • [175] The AutoDump Web Interface on Windows Server 2012 R2 or Windows 8.1: The AutoDump Web Interface component does not display on either Windows Server 2012 R2 or Windows 8.1. Version C.7 fixes this.
  • [176] The AutoDump Web Interface error page: The error page for the AutoDump Web Interface does not display normally. Version C.7 fixes this.
  • [182] VSP G1000 DAT generation halts on LuPath.dat: The SVP Agent hangs may hang on generation of LuPath.dat. Version C.7 fixes this.

Changes

  • [177] VSPG1000 Support Added: VSPG1000 systems are officially supported in version C.7.
  • [178] Collecting BatteryLifeEach Information: On HUS VM systems, Hi-Track uses an API to collect the life information of each battery.
  • [179] Adding an SR to AutoDumps generated from the Web Interface: Users may now attach an SR number to an AutoDump request submitted by the AutoDump Web Interface.
  • [180] Concurrent SIM transfer and AutoDump generation: AutoDump generation submitted by either the GUI or AutoDump Web Interface no longer blocks SIM transfer until the dump is generated.
  • [181] The MakeHiTrackDb utility defaults: The MakeHiTrackDb utility now points towards default installation locations.
C.6 January 22, 2014

Bug Fixes

  • [159] HUS VM SIM data corrupt: SIM messages transferred to Hi-Track from an HUS VM system with a serial number with leading zeros (after the leading "2" — i.e. "201234") were unreadable by the Hi-Track server. Version C.6 fixes this.
  • [160] HUS VM unable to determine the system type after install: The SVP Agent for an HUS VM system is unable to determine the system type upon a fresh install. Version C.6 fixes this.
  • [161] HiTrackLogs.zip fails to close: An open log file fails to zip during a transfer, causing the transfer to fail. Version C.6 fixes this.
  • [162] SIMs Report When They Should Not: SIMs reported to the Hi-Track Center regardless of the front's "Report SIMs" setting. Version C.6 fixes this.
  • [163] HUS VM SIM Emails Not Sent: SIMs reported to the Hi-Track Center were not emailed to their designated recipients. Version C.6 fixes this.
  • [164] HUS VM Serial Truncation: The serial numbers of HUS VMs dropped the leading '2' after certain UI interactions. Version C.6 fixes this.
  • [165] Duplicated localhost Subsystem Upon Install: The localhost subsystem entry is added twice to subsystems upon initial install. Occurs very rarely. Version C.6 fixes this.

Changes

  • [166] Collecting DKU Type Information: On HUS VM systems, Hi-Track uses a new API to collect the life information of each battery.
  • [167] Trigger AutoDumps from the Service Manager: AutoDumps can be generated and transferred to the Hi-Track Center from the Service Manager by either targeting a specific subsystem or all subsystems monitored by a Site Manager. This feature is supported on USP V/VM, VSP, and HUS VM.
  • [168] Trigger AutoDumps from a Web Interface: AutoDumps can be generated and transferred to the Hi-Track Center from a web interface if this feature is enabled on the Site Manager's Service Manager. This feature is supported on USP V/VM, VSP, and HUS VM.
  • [169] Trigger AutoDumps by SIM reference code: If enabled in the Service Manager, AutoDumps can be automatically generated and transferred to the Hi-Track Center if a reported SIM reference code matches one that's listed in the SIM AutoDump parameter file. This feature is supported on USP V/VM, VSP, and HUS VM.
  • [170] Includes Pre-populated HTTPS, FTPS, and FTP Contact Methods in the "Add Contact" dialog for the Hi-Track Service Manager.
  • [171] Changed Contact Method Passes to rotate through defined contact methods rather than try each method a specific number of times before moving on to another. Preference is given to IP transport methods and if these all fail within a timeout period then Dial-up transport methods are attempted. In addition, the default retries configuration parameters only apply to the dial-up transport methods. The IP transport methods are looped through where applicable until a transport timeout period elapses.
C.5 October 29, 2012

Bug Fixes

  • [157] VSP systems failing daily transfers: Under some circumstances Hi-Track Agent version C.4 on VSP systems running some versions of V-04 microcode would crash during file generation and fail to transfer data files to the Hi-Track Center. Version C.5 fixes this problem.
  • [158] Hi-Track Service Manager application prevents log off: Hi-Track Agent version C.4 installed on systems other than SVPs prevented the user from logging off of a console session unless the Service Manager application was closed. Version C.5 fixes this problem.
C.4 September 18, 2012

Bug Fixes

  • [149] Dial-up incidental calls send wrong micro-code version for back systems: Under some circumstances a dial-up incidental call would report an incorrect microcode version for remote systems reporting a SIM. Hi-Track C.4 fixes this issue.

Changes

  • [150] Support for HUS VM systems: Hi-Track was updated in C.4 to support HUS VM storage systems.
  • [151] Collecting Storage System Data in XML format: on HUS VM systems or VSP systems with micro-code version 7004000000 and above, Hi-Track calls the appropriate API functions to collect storage configuration data such as package information as well as SSB and SIM data. Moreover, Hi-Track transports these new XML data files during the daily and weekly data transports.
  • [152] Collecting Pool Information Ex2: On HUS VM systems or VSP systems with micro-code version 7004000000 and above, Hi-Track uses a new API to collect the ‘ex2’ version of the HDP pool data.
  • [153] Collecting License Information Ex: On HUS VM systems or VSP systems with micro-code version 7004000000 and above, Hi-Track uses a new API to collect the ‘ex’ version of License data.
  • [154] Collecting Each Battery Life Information: On HUS VM systems or VSP systems with micro-code version 7002500000 and above, Hi-Track uses a new API to collect the life information of each battery.
  • [155] Additional information included in SIM notification emails: Additional information including error location and HDD serial number (when applicable) is now included in notification email messages if the system is configured for email notification.
  • [156] Changed the Service Manager application to support minimize, restore, display in taskbar, and to not enforce an "always on top" window state.
C.3 May 1, 2012

Bug Fixes

  • [147] SVP Agent Service (BackSvc.exe) consumes a high percentage of CPU time: In Hi-Track C.2, if the SVP agent service runs continuously for a long period of time, it would eventually uses near 100% of the CPU. As a result, the Hi-Track application may not be able to write to log files or transport data to the center. We have reports indicating that the issue has occurred as early as 30 days after starting the SVP agent service. Hi-Track C.3 fixes this.
  • [148] Email Notification for Simultaneous SIMs: If simultaneous SIMs occur on an SVP, previous versions of Hi-Track may not send email notification for all of them. Hi-Track version C.3 was modified to send notification emails for all SIMs, including those that occur simultaneously.
C.2 October 31, 2011

Bug Fixes

  • [136] Upgrading Hi-Track: When installing Hi-Track C.1 on a system that is running a previous version of Hi-Track, the C.1 installer incorrectly displays a message indicating that Hi-Track C.1 is already installed and prompts the end-user to either repair or remove Hi-Track. In C2, Removing the previous version of Hi-Track is part of the installation process and does not require user intervention.
  • [137] SIMS Email Notification: Prior to version C.2, Hi-Track failed to send SIMS notification emails when deployed on a stand-alone system. Hi-Track C.2 fixes this.
  • [138] SMTP authentication: In previous versions of Hi-Track, users could specify the email server username and password in the Notification tab but the Hi-Track application did not forward the authentication credentials to the SMTP mail server. Version C.2 correctly sets the username and password if the SMTP server requires authentication.
  • [139] Site Manager Handle Count: if a dialup transport is defined as the only contact method and none of the dialup succeeds, the Hi-Track Site Manager consumes many file handles without releasing them. this is resolved in version C.2.
  • [140] Proxy Server Domain Authentication: Hi-Track version C.2 was modified to support domain authentication for proxy servers.

Changes

  • [141] Transporting Uncompleted SIMS: Hi-Track sends a list of uncompleted SIMs to the center during data transfer.
  • [142] Manual Contact Method: Hi-Track C.2 introduces a new contact method called Manual that stores the collected data in the c:\HDS\FtpStage instead of sending it to the Hi-Track center.
  • [143] Configurable SMTP Port: Allows users to specify the SMTP port for email event notification. The default port is 25.
  • [144] HTTPS as Default Transport Method: Previous versions of Hi-Track were pre-configured with a dial-up transfer method. This has been changed in C.2 and Hi-Track displays a generic HTTPS connection as the preferred transfer method. As a result, ‘Answer incoming calls’ and ‘Enable RAS dial-back’ checkboxes are in the unchecked state by default.
  • [145] Notification by SIM Severity: In version C.2, the Hi-Track application can be configured to send email notification based on the severity of SIMs.
  • [146] Validating SSL Certificate: Previous versions of Hi-Track rejected SSL certificates that were signed by untrusted authorities. Therefore, it was not possible to employ the HTTPS method to transfer data to servers with self-signed SSL certificate. In version C.2, Hi-Track can be configured to skip the server certificate validation process and transfer data to any web server via HTTPS.
C.1 July 27, 2010

Bug Fixes

  • [124] Collection of LUSE data: Prior to version C.1, Hi-Track did not completely retrieve the data about configured expanded LUSE. Version C.1 calls the appropriate APIs to collect all the LUSE information. It will gather the configured LUSE data on all the large RAID SVP types.
  • [125] Log sizes grow unexpectedly: There was one report suggesting that the Hi-Track log file size becomes too large and takes all the C drive space. To prevent this rare incident from happening, Hi-Track was modified to check the log size before writing to it. In version C.1 or later, Hi-Track will overwrite the log file if the file size exceeds 2 megabytes.
  • [126] Failing to FTPS to Solaris FTP Server: In rare occasions, Hi-Track reports an error when sending data via FTPS to Solaris FTP servers. Further investigation revealed that the error occurs on logoff event after data transfer is completed. Hi-Track version C.1 resolves this issue.
  • [127] Stopping Site Manager Service: If there is no modem attached to the Hi-Track host system, the Site Manager Service cannot be correctly stopped as it is waiting for a reply from an absent modem. Hi-Track C.1 resolves this issue.
  • [128] Reporting SSB data: Prior to version C.1, Hi-Track was not able to report all SSB data when the primary transfer protocol was HTTPS or FTP. This issue has been resolved in version C.1 and Hi-Track successfully transfers the SSB information to the center using HTTPS or FTP.
  • [#] Standby SVP Agents don't switch to primary: For dual SVPs, when the primary SVP Agent fails, the standby SVP agent does not automatically switch to a primary. Switching requires manually restarting the standby SVP Agent's service. Hi-Track C.1 resolves this issue.

Changes

  • [129] Support for VSP systems: VSP is the latest system of the large RAID family of HDS storage products. Hi-Track was updated in C.1 to fully support VSP storage systems.
  • [130] Dial-up configuration on VSP: Hi-Track does not support dial-up data transfer or RAS dial-back by default on VSP storage systems as these systems do not have a built-in modem. However, users can optionally install one of the modems that is supported by Hi-Track (please refer to the Hi-Track help document for the list of Hi-Track approved modems). In version C.1, the Hi-Track Service Manager is able to detect whether the host platform is equipped with a modem. It allows dial-up data transfer and RAS dial-back only if finds a modem on the startup event.
  • [131] Hi-Track Installation Location: In C.1, the Hi-Track installer will prompt the end-user to select a target installation directory. The default folder is “C:\Program Files\Hitachi Data Systems\Hi-Track\” for USP V/VM, NSC, and USP. For VSP, the default folder is “C:\Program Files (x86)\Hitachi Data Systems\Hi-Track.”
  • [132] FTPS to non-HDS Centers: Prior to version C.1, Hi-Track was able to only transfer data securely to HDS centers. This restriction has been modified in version C.1 and Hi-Track can send data to any server using the FTPS transfer protocol. To use FTPS to send data to a non-HDS center, uncheck the box labeled Transfer to HDS only on the FTP Method Properties panel.
  • [133] Collecting and Transporting csv.zip: If the appropriate command-line tool is installed on an SVP, Hi-Track will call it to collect the csv.zip data. Similar to dat.zip and config.zip, the csv.zip is stored in c:\hds and sent to the HDS center during data transfer.
  • [134] SVP Agent Connectivity Test: In Hi-Track version B.D to C.0, any Vista computer failed the Ping portion of the SVP Agent Connectivity Test facility of the Hi-Track Service Manager. Hi-Track version C.1 was updated to resolve this problem.
  • [135] Collection of SVP Antivirus data: Starting with version C.1, Hi-Track uses a different method to retrieve information from any antivirus installed on the host system. The new method works on all SVP types.
C.0 June 4, 2009

Bug Fixes

  • [117] FCGS Symbolic data collection caused Hi-Track failures: Item #116 in version B.F was modified to only generate FCGS symbolic data if the USPV/VM subsystem is at or above the V04+1 microcode level. A workaround that was offered for this problem was to uncheck the box in the Service Manager program to disallow collection of FCGS data. If you cleared this checkbox to work around the problem, please replace the check in the checkbox after upgrading to C.0 and test a full transfer (including new file generation) to the Hi-Track Center. Watch both the Site Manager log and Agent log during file generation and transfer to ensure that it completes without errors.
  • [118] Testing transfers in the Service Manager: If a user initiated a test Daily transfer in the Service Manager program and the day of the week was the same as the day of the week the system was configured to do weekly transfers, the call type would be changed to Weekly.
  • [119] System Busy message: When attempting to initiate a data transfer to the Hi-Track Center while connected through a RAS session, the Hi-Track agent would respond that the system was busy regardless of the configured transport methods. Version C.0 will allow a transfer provided that the primary transport method is not dialup.

Changes

  • [120] Collection of HDP data: A new API was added for USPV/VM systems to collect information about configured HDP pools and volume information. This API will be called and the data collected for systems running microcode versions V05 and above. This information is displayed on the Hi-Track web pages for USP V and USP VM systems configured with HDP pools and volumes.
  • [121] FTP data transfers changed to PUT: For historical reasons, in the past FTP transfers to the Hi-Track Center have appended files to the Hi-Track FTP servers. With this version FTP transfers have been changed to uploads which will overwrite any existing files. This change will prevent misconfigured agents from causing problems with the Hi-Track FTP servers.
  • [122] Installer change: A change was made to the agent bootstrap installer to automatically remove previous versions of the Hi-Track agent before installing a new version. This should result in a higher success rate for upgrade installs.
  • [123] Return value from dialup command changed: The return value for a dialup Center command was changed in this version to acknowledge the command sent.