<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Upgrading WebSphere Application Servers &#8211; Update the Deployment Manager First!</title>
	<atom:link href="http://blog.danzrobok.com/2009/07/29/upgrading-websphere-application-servers-update-the-deployment-manager-first/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.danzrobok.com/2009/07/29/upgrading-websphere-application-servers-update-the-deployment-manager-first/</link>
	<description>Business Integration and SOA with an IBM WebSphere slant</description>
	<lastBuildDate>Fri, 18 Nov 2011 18:21:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1</generator>
	<item>
		<title>By: Franch</title>
		<link>http://blog.danzrobok.com/2009/07/29/upgrading-websphere-application-servers-update-the-deployment-manager-first/comment-page-1/#comment-9820</link>
		<dc:creator>Franch</dc:creator>
		<pubDate>Thu, 30 Jul 2009 07:01:27 +0000</pubDate>
		<guid isPermaLink="false">http://blog.danzrobok.com/2009/07/29/upgrading-websphere-application-servers-update-the-deployment-manager-first/#comment-9820</guid>
		<description>Of course but the node agents communicates, our consultant told us that the must run the same software version same FP and same ifix to avoid problems...
After updating one node, we have to start it before stop the other, during this time (could be few seconds) our cluster members are not running the same version</description>
		<content:encoded><![CDATA[<p>Of course but the node agents communicates, our consultant told us that the must run the same software version same FP and same ifix to avoid problems&#8230;<br />
After updating one node, we have to start it before stop the other, during this time (could be few seconds) our cluster members are not running the same version</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dan</title>
		<link>http://blog.danzrobok.com/2009/07/29/upgrading-websphere-application-servers-update-the-deployment-manager-first/comment-page-1/#comment-9809</link>
		<dc:creator>dan</dc:creator>
		<pubDate>Wed, 29 Jul 2009 17:14:16 +0000</pubDate>
		<guid isPermaLink="false">http://blog.danzrobok.com/2009/07/29/upgrading-websphere-application-servers-update-the-deployment-manager-first/#comment-9809</guid>
		<description>Well the whole point of having a cluster is for failover and high availability (assumping an http server in there somewhere). If you have two servers in a cluster, you can take server1 down while failover will redirect traffic to server2.</description>
		<content:encoded><![CDATA[<p>Well the whole point of having a cluster is for failover and high availability (assumping an http server in there somewhere). If you have two servers in a cluster, you can take server1 down while failover will redirect traffic to server2.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Franch</title>
		<link>http://blog.danzrobok.com/2009/07/29/upgrading-websphere-application-servers-update-the-deployment-manager-first/comment-page-1/#comment-9808</link>
		<dc:creator>Franch</dc:creator>
		<pubDate>Wed, 29 Jul 2009 16:14:28 +0000</pubDate>
		<guid isPermaLink="false">http://blog.danzrobok.com/2009/07/29/upgrading-websphere-application-servers-update-the-deployment-manager-first/#comment-9808</guid>
		<description>Ok, thanks for your answer, I was wondering about this subject because all the IBM software consultants we met told us that there is no way to avoid the production interuption</description>
		<content:encoded><![CDATA[<p>Ok, thanks for your answer, I was wondering about this subject because all the IBM software consultants we met told us that there is no way to avoid the production interuption</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dan</title>
		<link>http://blog.danzrobok.com/2009/07/29/upgrading-websphere-application-servers-update-the-deployment-manager-first/comment-page-1/#comment-9807</link>
		<dc:creator>dan</dc:creator>
		<pubDate>Wed, 29 Jul 2009 16:10:30 +0000</pubDate>
		<guid isPermaLink="false">http://blog.danzrobok.com/2009/07/29/upgrading-websphere-application-servers-update-the-deployment-manager-first/#comment-9807</guid>
		<description>Of for sure, once you have updated the deployment manager, you can then perform your upgrades by taking one node down, upgrading, starting and then taking the other node down.

There&#039;s no issue with having different levels of WAS inside your cluster, it&#039;s just that the DMGR always has to have the highest fixpack in the group.</description>
		<content:encoded><![CDATA[<p>Of for sure, once you have updated the deployment manager, you can then perform your upgrades by taking one node down, upgrading, starting and then taking the other node down.</p>
<p>There&#8217;s no issue with having different levels of WAS inside your cluster, it&#8217;s just that the DMGR always has to have the highest fixpack in the group.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Franch</title>
		<link>http://blog.danzrobok.com/2009/07/29/upgrading-websphere-application-servers-update-the-deployment-manager-first/comment-page-1/#comment-9806</link>
		<dc:creator>Franch</dc:creator>
		<pubDate>Wed, 29 Jul 2009 15:56:28 +0000</pubDate>
		<guid isPermaLink="false">http://blog.danzrobok.com/2009/07/29/upgrading-websphere-application-servers-update-the-deployment-manager-first/#comment-9806</guid>
		<description>But after updating the DMGR, could we update one node, restart it and then stop and update the second node? (In this case each node had a specific runtime)</description>
		<content:encoded><![CDATA[<p>But after updating the DMGR, could we update one node, restart it and then stop and update the second node? (In this case each node had a specific runtime)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

