Highlighted
2 Bronze

Re: SAN HQ enquiry

Jump to solution

Crescendas,

 The ethernet ports that must be reachable by the SAN HQ Server will depend on how your group is configured.  If you have fully configured a dedicated management network then SAN HQ will require access to the Group's Management IP address, this is separate from your Group iSCSI IP address, and each member's dedicated management ethernet port.  If you are not using a dedicated management network then SAN HQ will require access to the Group's (iSCSI) IP address and at least one ethernet port on each member.

 The SAN HQ Server does not need to use SNMP traps so adding the Server's IP address to the list of trap destinations would not be beneficial.

 When you configure SANAssist on a group you are required to add the SAN HQ Server's IP address to the list of syslog message servers.  This enables SANAssist's Event Driven data collection, in addition to the standard Weekly and On-Demand.  An Event Driven data collection is triggered when the SAN HQ Server receives a critical event notification through the syslog mechanism.

 The recommended practice for a remote site using a WAN connection is to have a secondary SAN HQ Server deployed locally at the remote site and configured to connect to all your PS Series groups locally.  You can then use a remote, client only, SAN HQ installation to connect to multiple SAN HQ Servers over the WAN connection.  This will allow the SAN HQ Server to utilize the faster local network for all standard data polling and SANAssist functionality in addition to not requiring you to expose your management or iSCSI network over the WAN.

 In response to your outstanding issue #2, this is most likely caused by you adding the group using an incorrect well known address.  If your group is fully configured for dedicated management only traffic, you should double check that the IP address you used to add the group matches the IP address specified in the Group Manager in the Group Configuration 'Advanced' tab.  If your group is partially configured for dedicated management only traffic then you may receive these types of alerts and experience issues when configuring SANAssist.

 In response to issue #3, can you verify that your SAN HQ Server's IP address is listed in the Group Manager's Group Configuration under the 'Notifications' tab?  The IP Address should be displayed under the 'Event Logs' section and the checkbox 'Send events to syslog servers' should be checked.  If not, please add the IP address to the list and check the checkbox then click the save 'Disk' icon at the top right of the Group Manager.  If this does not resolve your issue, you may need to verify that your network is not blocking UDP traffic over port #514 and that the system running your SAN HQ Server does not have another syslog service installed.

 Issue #4 is most likely related to why you are seeing the alert for issue #2.  Can you verify your group configuration is either fully configured for dedicated management traffic or if you are not using a dedicated management traffic that none of your members are configured with an active management-only ethernet port?  Once that has been resolved, please try to configure SANAssist on your group again and let me know the result.

View solution in original post

Highlighted
2 Iron

Re: SAN HQ enquiry

Jump to solution

Hi, the issues have been resolved by completely uninstalling SanHQ and remove all logs and settings, then reinstall it again. It appears that previous conflicting settings are retained when I remove and add EQL back into SanHQ!

View solution in original post

Highlighted
2 Bronze

Re: SAN HQ enquiry

Jump to solution

I have a similar issue to the one described in this thread.

I have just installed a new vewsion of SAN HQ (2.6), and copied the logs over from our old SAN HQ server.

Now the new server is complaining about the WKA addresses. Is it possible to correct the WKA addresses and retain our old logs? I ask because it looks like the SAN IP addresses are embedded in the filenames of the logs. So, if I reconnect the groups to SAN HQ, will I lose I logs?

Can I maybe rename the logs files to match the WKA addresses?

0 Kudos
Highlighted
2 Bronze

Re: SAN HQ enquiry

Jump to solution

JonB999,

  The standard practice in this scenario is to stop monitoring on the group using an incorrect WKA and re-add the group using the new WKA.  Additional details are available in the SAN Headquarters Release Notes under the heading ‘Handling Group Address Changes.’

 You can attempt renaming the files associated with the group, however this is not a supported operation.  If you choose to perform this operation it’s recommended that you create a SAN HQ Archive of the group (or a backup of the entire log directory) beforehand.  Here’s a step by step guide to renaming the necessary files/details for a WKA address change:

1. If you have configured SupportAssist, previously called SANAssist, for the group you should delete the group’s configuration using the SupportAssist settings page.

2. Close all active SAN Headquarters Clients

3. Stop the SAN HQ Service (it is called Eqlxperf in Windows services)

4. Navigate to the SAN HQ log directory.

5. Rename both of the group’s .GRPDESC files to the appropriate name.  For example:

a. GroupDescriptorC192.168.2.2.grpdesc GroupDescriptorC[New WKA Address Here].grpdesc

b. GroupDescriptorS192.168.2.2.grpdesc GroupDescriptorS[New WKA Address Here].grpdesc

6. Open each of the .GRPDESC files in notepad or your standard text editor and modify the following two entries:

a. <GroupIPAddress>[New WKA Address Here]</GroupIPAddress>

b. <ResolvedConnectionIpAddress>[New WKA Address Here]< ResolvedConnectionIpAddress>

7. Rename all of the group’s *.GRPLOG files to the appropriate name.  For example:

a. GRP192.168.2.2FREQ0.grplog  GRP[New WKA Address Here]Freq0.grplog

b. GRP192.168.2.2SysLog.grplog  GRP[New WKA Address Here]Syslog.grplog

8. Rename all of the group’s *.XML files to the appropriate name.  For example:

a. GRP192.168.2.2FREQ0.xml  GRP[New WKA Address Here]Freq0.xml

9. Restart the SAN HQ Service

10. Launch the SANHQ Client

 As I stated, this is not a standard operation and may result in corruption of this group’s log data.  If you perform this operation without taking a backup of your data then all group specific information may be lost.

Highlighted
2 Bronze

Re: SAN HQ enquiry

Jump to solution

Thank you very much napalmer7, that procedure worked perfectly!

0 Kudos
Highlighted
2 Iron

RE: SAN HQ enquiry

Jump to solution

Recently, I'm forced to deploy a new SANHQ 3 on Windows 8 because it no longer support Windows XP where SANHQ 2.5 was installed and there is no direct upgrade path from XP to 8.

But the SANHQ 2.5 client was installed on a Windows 7, so it can upgrade directly to SANHQ 3. However, because the new SANHQ 3 is now on another IP address, the client insist to connect to the old IP address. Is there a way to update the IP address from 192.168.100.46/log to 192.168.100.47/monitor as I can't it anywhere in the client menu:

0 Kudos
Highlighted

RE: SAN HQ enquiry

Jump to solution

I believe you have to set the other SANHQ server as default, then remove the old entry and add in the new one.  

Social Media and Community Professional
#IWork4Dell
Get Support on Twitter - @dellcarespro

0 Kudos
Highlighted
3 Silver

RE: SAN HQ enquiry

Jump to solution
While were on the discussion of SANHQ, riddle me this Bat Man... Our HQ SAN, PS6500, with 21.12TB of member space and 7.0.4 firmware, now shows expired under Group Configuration / General tab / SAN Headquaters, bottom of screen, for SAN HQ registration, WT?, date last monitored 5/23/2014 at 5:12pm Although, within SAN HQ 3.0, it still shows stats for today, yesterday, etc....Green status. What is dealio Coolio? SAN HQ 3.0 and 7.0.4 have some buggies?
0 Kudos
Highlighted

RE: SAN HQ enquiry

Jump to solution

Hello Vmbru,

It's not polite forum ettiquite to hijack a thread with a new issue.   Makes it much harder to follow the conversation.

It's always best to start a new topic with each new issue or question.  

There are no known issues that I am aware of that covers this behaviour.  I would suggest opening a support case so they can look at the logs.

Regards,

Social Media and Community Professional
#IWork4Dell
Get Support on Twitter - @dellcarespro

0 Kudos
Highlighted
2 Bronze

RE: SAN HQ enquiry

Jump to solution

1) I have set email notification. But i can see notification is not regular when i closed SAN HQ. Will the service be running even after i close SAN HQ? if so why am i not getting regular notification.

2) If i want to notified snmp traps too. what is the SNMP notification destination address i should give?

0 Kudos