We name our workstations according to their serial number, which happens to be all numeric. Our server lists all the remote agents (workstations) at the local facility. I use a script to query AD for the workstations in the local site and populate the server with workstation names. When I test connection, I get an error (Distributed Communication Error). For example, the worksation has the name of 9991012345678. If I add a char to the beginning of the name it works. For example: a9991012345678. It looks as if I can't name the workstations starting with a numeric. This really blows our whole naming scheme out of the water. Is there any way this can be changed or fixed? I am not sure if it is a bug or by design.

Thanks,

Mike Niccum

The WinSock interface treats numeric only names as IP addresses that's why it cannot make the connection. I think this is a generic issue which is not specific to 24x7. You should not use numeric names.

A workaround in 24x7 would be to use Named Pipes inteface instead of WinSock.

: We name our workstations according to their serial number, which happens to
: be all numeric. Our server lists all the remote agents (workstations) at
: the local facility. I use a script to query AD for the workstations in the
: local site and populate the server with workstation names. When I test
: connection, I get an error (Distributed Communication Error). For example,
: the worksation has the name of 9991012345678. If I add a char to the
: beginning of the name it works. For example: a9991012345678. It looks as
: if I can't name the workstations starting with a numeric. This really
: blows our whole naming scheme out of the water. Is there any way this can
: be changed or fixed? I am not sure if it is a bug or by design.

: Thanks,

: Mike Niccum

Thank you for your quick response... Here is what I have found with your suggegstions..

I configured a remote agent to use named pipes, and its location was not completely numbers... it just started with a number. here is what i tried.

9991fghxe589.beverlyhealth.com
9991fghxe589

both of those settings give data communication errors when i try to use WINSOCK or NAMED PIPES. If i rename the computer to start with a letter
a9991fghxe589
it works fine....
any other suggestions?

: The WinSock interface treats numeric only names as IP addresses that's why it
: cannot make the connection. I think this is a generic issue which is not
: specific to 24x7. You should not use numeric names.

: A workaround in 24x7 would be to use Named Pipes inteface instead of WinSock.

Can you use IP address instead of computer name?

: Thank you for your quick response... Here is what I have found with your
: suggegstions..

: I configured a remote agent to use named pipes, and its location was not
: completely numbers... it just started with a number. here is what i tried.

: 9991fghxe589.beverlyhealth.com
: 9991fghxe589

: both of those settings give data communication errors when i try to use
: WINSOCK or NAMED PIPES. If i rename the computer to start with a letter
: a9991fghxe589
: it works fine....
: any other suggestions?

: Can you use IP address instead of computer name?

I'm not sure if the issue is Winsock or 24x7, but our
research and testing indicates it may be within 24x7.

We can ping the computername that begins with a digit.
We have other TCP apps on Windows that accept this
computername and resolve it to its IP address.
This seems to remove winsock as the problem.

RFC1123 specifies that a host name may begin with a
digit. Can you please look into this some more to
see if 24x7 is by chance not RFC1123 compliant?

Thank you,
Greg

The problem is not really with the name, the name is unusual but valid and there is no crossed RFC limitations.

The problem is the way the name is treated. 24x7 internally uses Sybase networking components for agent communications. These components can accept both IP addresses and computer names. I guess they contain some piece of incorrect logic that checks what kind of connection information is passed. When it finds digits only in the destination name it assumes that an IP address is passed. Of course the connection then fails because the destination name is no an IP address.

I don't think anything can be done quickly to correct the issue. It is also my understanding that you use some kind of dynamic IP schema and that's why you cannot use IP addresses. I suggest you find some workaround to deal with the issue. For example if you name agents as machine names you can create a job that will periodically run a ping each agent using the command line ping utility. The job can capture the output of ping command and use the reported agent's IP address to update agent information in the registry.

Example JAL script to return comma-separated list of all configured 24x7 Remote Agent profiles:

Dim( host_list, string )
RegistryList( "HKEY_LOCAL_MACHINE\SOFTWARE\SoftTree Technologies, Inc.\24x7 Scheduler\3.0\Agents", "SUBKEYS", host_list )

If you need further help with this job please let me know.

: I'm not sure if the issue is Winsock or 24x7, but our
: research and testing indicates it may be within 24x7.

: We can ping the computername that begins with a digit.
: We have other TCP apps on Windows that accept this
: computername and resolve it to its IP address.
: This seems to remove winsock as the problem.

: RFC1123 specifies that a host name may begin with a
: digit. Can you please look into this some more to
: see if 24x7 is by chance not RFC1123 compliant?

: Thank you,
: Greg

Another workaround that might work for you is to use full machine names including the domain: machine.domain, for example 1234567890.netdomain.

If your domain name is not numeric like names of agent computers the full names will make the networking component to treat it as a computer name and not as IP address.

: The problem is not really with the name, the name is unusual but valid and
: there is no crossed RFC limitations.

: The problem is the way the name is treated. 24x7 internally uses Sybase
: networking components for agent communications. These components can
: accept both IP addresses and computer names. I guess they contain some
: piece of incorrect logic that checks what kind of connection information
: is passed. When it finds digits only in the destination name it assumes
: that an IP address is passed. Of course the connection then fails because
: the destination name is no an IP address.

: I don't think anything can be done quickly to correct the issue. It is also
: my understanding that you use some kind of dynamic IP schema and that's
: why you cannot use IP addresses. I suggest you find some workaround to
: deal with the issue. For example if you name agents as machine names you
: can create a job that will periodically run a ping each agent using the
: command line ping utility. The job can capture the output of ping command
: and use the reported agent's IP address to update agent information in the
: registry.

: Example JAL script to return comma-separated list of all configured 24x7
: Remote Agent profiles: Dim( host_list, string )
: RegistryList( "HKEY_LOCAL_MACHINE\SOFTWARE\SoftTree Technologies,
: Inc.\24x7 Scheduler\3.0\Agents", "SUBKEYS", host_list )

: If you need further help with this job please let me know.

Thank you for your time. Our computernames begin with a
digit, but they also contain alpha characters. We have
tried the fully qualified host names, but to no avail.
I guess the Sybase logic makes a decision off the 1st
character. We've developed some workaround code, but
are also evaluating changing our naming scheme.

: Another workaround that might work for you is to use full machine names
: including the domain: machine.domain, for example 1234567890.netdomain.

: If your domain name is not numeric like names of agent computers the full
: names will make the networking component to treat it as a computer name
: and not as IP address.