Hello,

We are experience an intermittant issue with our SCOM to HPOM SCInterOP connector. We are having an issue where the SCOM RMS server  name  is being passed to HPOM as the node name for alerts when in SCOM the node name is a completely diferent server.

An example would be an IIS appplication pool error that is generated. The path for the alert will specificy a SCOM Agent node, such as "server1.acme.com", however when the event is generated in HPOM the node name will come up with our SCOM RMS server name eg: "scomsrv1.acme.com".

We have an automated ticketing system which then generates a ticket in our service desk application however when this situation occurs it is very difficult for a non SCOM people to acurately determine what server is actually generating the error.

We are are running SCOM 2007 R2 CU6 and our HP OM server is 8.10 with the latest patches applied.

Any asistance would be much appreciated.

Regards

Tony

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Tony,

There are 2 issues that can cause this.

1 - The node name of the IIS server 'server1.acme.com' fails DNS lookup and the connector reverts to the the RMS server name to guarantee the alert is delivered to HPOM.

2 - The connector uses the PrincipleName of the alert generated from SCOM. If the name does not resolve in DNS the connector will revert to the RMS server and use that to guarantee delivery to HPOM. There are a few MPs out there that do not set the PrincipleName correctly in the alert which causes this issue and it is really an MP issues and not a connector issues.

There's an internal doc that addresses this and provides a workaround. If you'd like a copy you can send and email to something@microsoft.com and replace the something with xplatext.

Regards,

-Steve

• Edited by Steve Weber [MSFT]Microsoft employee, Moderator Monday, August 13, 2012 1:40 PM
• Marked as answer by Steve Weber [MSFT]Microsoft employee, Moderator Wednesday, August 15, 2012 2:31 PM

Hi Steve,

Thanks for the information.

This makes sense as the majority of our impacted servers are in the DMZ which cannot be resolved via DNS for obvious reasons.

As suggested I have requested a copy of the internal documentation that may help us to overcome this issue.

In the meantime if you have any other suggestions to try it would be much appreciated.

Regards,

Tony

Tony,

If you know the actually server names and there are not too many you could try to add them to the hosts file on the server the connector is installed on and it should resolve them without needing to be in DNS.

Regards,

-Steve

Hi Steve,

Thats a good idea.

We have approximately 20 servers in that situation so we may look at that solution as well.

Regrads,

Tony Anton

Hi Steve,

I am experiencing this same issue, but it appears that the email address you provided is no longer valid as I received a delivery failure.

Would you be able to provide an updated email address?

Thanks!

Jim

Jim,

Use scxtest and replace the something.

Regards,

-Steve

Thanks Steve. I sent an email as instructed.

I have an open support case with Premier service, but the engineer assigned says he is unable to locate the internal document.

How long should I expect to wait for a reply from the email address you provided. I included my case # with the email.

Thanks again!

Jim,

Got the email and doc has been sent.

-Steve