HI,

I have 2 nodes on cluster. I installed SQL clustering. Recently, there is a
need to have IP changes to the environment. I followed closely from Microsoft
KB article

Changing the IP address of network adapters in cluster server
http://support.microsoft.com/kb/230356

How to change the network IP addresses of SQL Server failover cluster
instances
http://support.microsoft.com/kb/244980

But unfortunately, after changing the IP. I have problem restarting the SQL
Server service and SQL Server Agent service with error below.

Event Type: Error
Event Source: MSSQL$SQL1
Event Category: (3)
Event ID: 19019
User: N/A
Computer: SQLNODE1
Description:
[sqsrvres] OnlineThread: Error 5b4 bringing resource online

Event Type: Error
Event Source: MSSQL$SQL1
Event Category: (3)
Event ID: 19019
User: N/A
Computer: SQLNODE1
Description:
[sqsrvres] OnlineThread: ResUtilsStartResourceService failed (status 5b4)

I verified that all the SAN allocations can be accessed and brought online
in the cluster admin.

I really need help. Many thanks in advance

Make sure your cluster is not split-brained. That is it communicates
cleanly between the nodes. Changes in clustered resource status on one node
should be immediately mathced on the other.

If you change the subnet mask for the cluster, it thinks it is a new network
and you must map the SQL IP resource to that cluster network. Also check
that the SQL IP resource subnet matches the physical IP subnet.

--
Geoff N. Hiten
Principal SQL Infrastructure Consultant
Microsoft SQL Server MVP




"irewan" <irewan (AT) chassasia (DOT) com> wrote

Make sure your cluster is not split-brained. That is it communicates
cleanly between the nodes. Changes in clustered resource status on one node
should be immediately mathced on the other.

If you change the subnet mask for the cluster, it thinks it is a new network
and you must map the SQL IP resource to that cluster network. Also check
that the SQL IP resource subnet matches the physical IP subnet.

--
Geoff N. Hiten
Principal SQL Infrastructure Consultant
Microsoft SQL Server MVP




"irewan" <irewan (AT) chassasia (DOT) com> wrote

Make sure your cluster is not split-brained. That is it communicates
cleanly between the nodes. Changes in clustered resource status on one node
should be immediately mathced on the other.

If you change the subnet mask for the cluster, it thinks it is a new network
and you must map the SQL IP resource to that cluster network. Also check
that the SQL IP resource subnet matches the physical IP subnet.

--
Geoff N. Hiten
Principal SQL Infrastructure Consultant
Microsoft SQL Server MVP




"irewan" <irewan (AT) chassasia (DOT) com> wrote

Make sure your cluster is not split-brained. That is it communicates
cleanly between the nodes. Changes in clustered resource status on one node
should be immediately mathced on the other.

If you change the subnet mask for the cluster, it thinks it is a new network
and you must map the SQL IP resource to that cluster network. Also check
that the SQL IP resource subnet matches the physical IP subnet.

--
Geoff N. Hiten
Principal SQL Infrastructure Consultant
Microsoft SQL Server MVP




"irewan" <irewan (AT) chassasia (DOT) com> wrote

Make sure your cluster is not split-brained. That is it communicates
cleanly between the nodes. Changes in clustered resource status on one node
should be immediately mathced on the other.

If you change the subnet mask for the cluster, it thinks it is a new network
and you must map the SQL IP resource to that cluster network. Also check
that the SQL IP resource subnet matches the physical IP subnet.

--
Geoff N. Hiten
Principal SQL Infrastructure Consultant
Microsoft SQL Server MVP




"irewan" <irewan (AT) chassasia (DOT) com> wrote

Make sure your cluster is not split-brained. That is it communicates
cleanly between the nodes. Changes in clustered resource status on one node
should be immediately mathced on the other.

If you change the subnet mask for the cluster, it thinks it is a new network
and you must map the SQL IP resource to that cluster network. Also check
that the SQL IP resource subnet matches the physical IP subnet.

--
Geoff N. Hiten
Principal SQL Infrastructure Consultant
Microsoft SQL Server MVP




"irewan" <irewan (AT) chassasia (DOT) com> wrote

Make sure your cluster is not split-brained. That is it communicates
cleanly between the nodes. Changes in clustered resource status on one node
should be immediately mathced on the other.

If you change the subnet mask for the cluster, it thinks it is a new network
and you must map the SQL IP resource to that cluster network. Also check
that the SQL IP resource subnet matches the physical IP subnet.

--
Geoff N. Hiten
Principal SQL Infrastructure Consultant
Microsoft SQL Server MVP




"irewan" <irewan (AT) chassasia (DOT) com> wrote

Make sure your cluster is not split-brained. That is it communicates
cleanly between the nodes. Changes in clustered resource status on one node
should be immediately mathced on the other.

If you change the subnet mask for the cluster, it thinks it is a new network
and you must map the SQL IP resource to that cluster network. Also check
that the SQL IP resource subnet matches the physical IP subnet.

--
Geoff N. Hiten
Principal SQL Infrastructure Consultant
Microsoft SQL Server MVP




"irewan" <irewan (AT) chassasia (DOT) com> wrote

Make sure your cluster is not split-brained. That is it communicates
cleanly between the nodes. Changes in clustered resource status on one node
should be immediately mathced on the other.

If you change the subnet mask for the cluster, it thinks it is a new network
and you must map the SQL IP resource to that cluster network. Also check
that the SQL IP resource subnet matches the physical IP subnet.

--
Geoff N. Hiten
Principal SQL Infrastructure Consultant
Microsoft SQL Server MVP




"irewan" <irewan (AT) chassasia (DOT) com> wrote