HP StorageWorks Storage Mirroring application notes Guidelines for networking and failover (T2558-96063, February 2008)

6
to it as the “NetBIOS-less” transport, even while mentioning that the NET CONFIG SERVER command will
report the binding as
NetbiosSmb (000000000000). Regardless, this document will refer to it as SMB/IP
for the sake of convenience.
The NetBT bindings are displayed with the network adapter's Globally Unique Identifier (GUID) and MAC
address as:
NetBT_Tcpip_{030319AA-84D2-481D-8E28-1EAC6D4AF2A8} (000102d03b7d)
The netstat -a command returns display names for ports 139 and 445 as netbios-ssn and
microsoft-ds respectively.
Due to the differences between operating system versions, behavior of client/server communications after
Storage Mirroring failover will vary depending on the operating system version of the clients and server.
When Storage Mirroring failover occurs, the source IP address is added as a secondary IP address by
default. Accordingly, if either the target server or clients are pre-Windows 2000 systems, one of the
following is required in order for clients to access files on the target using the source's NetBIOS name:
• WINS and DNS servers must be updated so the source NetBIOS and host name resolve to a primary IP
address on the target
• The IP address of the source must be made a primary IP address on the target (the “replace” option)
If all clients and the target server are Windows 2000 or later, WINS and DNS do not need to be updated
if the source IP address is failed over. The clients, using SMB/IP, can connect to the target server with either
the source or target IP address, so it does not matter which IP address the source name resolves to.
Microsoft Knowledge Base article 142309 lists the order of name resolution methods used by clients when
resolving a NetBIOS name:
1. NetBIOS name cache
2. WINS server
3. B-node broadcast
4. LMHOSTS file
5. HOSTS file
6. DNS server
Failover and WINS
When Storage Mirroring failover occurs, Windows becomes aware of the new name that the server now
owns and initiates a WINS registration with the target's primary WINS server. This registration associates
the source name with the target's primary IP addresses and will be distributed to other WINS servers on
the network via WINS replication. The length of time required for all WINS servers to obtain the new
registration will depend on the number of WINS servers, the architecture of WINS replication, and the
interval of replication. If there is only one WINS server or if the target and all clients that need access are
configured with the same primary WINS server, then no additional configuration is necessary.
However, if some or all clients are configured with primary WINS servers other than the target's primary
WINS server, failover scripts can be used to make the necessary WINS registrations on all WINS servers
or to initiate WINS replication. The first method, making the WINS registrations, incurs less network
overhead, but will require the appropriate permissions (administrator group membership) on all WINS
servers. The second method, initiating WINS replication, will rely on the WINS infrastructure to distribute
the new records, but will require the system and network resources required to complete WINS replication.
The impact of WINS replication will depend on the size of the network and the WINS architecture.
WINS management scripting
WINS registrations can be made via scripts as part of the failover process. This can be accomplished by
using the Windows Resource Kit WINS Administration Tool (
winscl.exe) or the Windows 2000 NETSH
command in the failover script to either initiate WINS replication or make the appropriate registration with
each WINS server.
• WINS scripting is required when some or all clients have a primary WINS server other than the
target's primary WINS server, the target server or any clients are pre-Windows 2000 systems, and the
“replace” failover option is not used.