|
Home > Archive > BizTalk Server Setup > December 2005 > SSO Configuration for High Availability
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
SSO Configuration for High Availability
|
|
| Chris Cichocki 2005-10-13, 6:00 pm |
| We have a multiple server installation of BizTalk Server 2004 that we are
trying to configure for high availability. I followed the instructions in
the article "How to cluster the Enterprise Single Sign-On (SSO) service on
the master secret server in BizTalk Server 2004", and I believe that
everything is configured correctly.
When I went to do the BizTalk Server installation on a separate server, I
unchecked the "Enterprise Single Sign-On" and "Enterprise Single Sign-On
Administration" check boxes, but it installed the Enterprise Single Sign-On
service and administration tools anyway...
Does the service running on the BizTalk Server run and connect to the
service running in the cluster?? Or is it using the local service in place
of the clustered service?
The way this turned out seems either wrong or very confusing...
Thanks,
Chris
| |
| Alan Smith 2005-10-24, 10:32 am |
| Hi,
Each BizTalk server needs to have the SSO service installed on it. Within
your group of servers, one of the SSO servers will act as Master Secret
Server (MSS). The MSS stores the SSO Master Secret, and supplies it to the
SSO service on the other servers when they start up. The MMS should be
clustered to provide the high availability.
The SSO service on the other servers will cache the master secret in memory.
If the MSS is unavailable for a short time, BizTalk will be able to use this
cached master secret, and continue processing messages. If the SSO service is
re-started when the MSS is unavailable, it will not be able to retrieve the
master secret, and BizTalk will fail to start.
When you install BizTalk on other servers, you should have SSO seelcted for
install. When you configure BizTalk, you should specify that the SSO service
will NOT act as the master secret server.
There is also an option to promote any SSO server in the group to MSS, you
will need the backup of your master secret to do this. It's worth labbing
with this in a test environemnt to learn how this works, and include the
process in any disaster recovery policy.
--
The Bloggers Guide to BizTalk
http://geekswithblogs.com/asmith
"Chris Cichocki" wrote:
> We have a multiple server installation of BizTalk Server 2004 that we are
> trying to configure for high availability. I followed the instructions in
> the article "How to cluster the Enterprise Single Sign-On (SSO) service on
> the master secret server in BizTalk Server 2004", and I believe that
> everything is configured correctly.
>
> When I went to do the BizTalk Server installation on a separate server, I
> unchecked the "Enterprise Single Sign-On" and "Enterprise Single Sign-On
> Administration" check boxes, but it installed the Enterprise Single Sign-On
> service and administration tools anyway...
>
> Does the service running on the BizTalk Server run and connect to the
> service running in the cluster?? Or is it using the local service in place
> of the clustered service?
>
> The way this turned out seems either wrong or very confusing...
>
> Thanks,
> Chris
| |
| Chris Cichocki 2005-10-24, 10:32 am |
| Thanks Alan. This helps, but I still have a couple questions...
It seems that there always needs to be a "Master" for the SSO service, and
we configured the first node in our cluster (only used to run the SSO
service) to be the master. If the first node should fail, the second node
becomes the active node in the cluster and the SSO service is started.
Does this failover process promote the second node to the "Master" server
for the SSO service, or is the cluster itself considered the master and then
whatever node is active is the one servicing the requests?
Also, the instructions explicitly tell you to restore the secret to the
second node in the cluster, but it doesn't tell you whether or not you should
restore the secret on the servers running the BizTalk engine. Should all
servers running the SSO service have the same secret restored?
Thanks for your help.
Chris
"Alan Smith" wrote:
[vbcol=seagreen]
> Hi,
>
> Each BizTalk server needs to have the SSO service installed on it. Within
> your group of servers, one of the SSO servers will act as Master Secret
> Server (MSS). The MSS stores the SSO Master Secret, and supplies it to the
> SSO service on the other servers when they start up. The MMS should be
> clustered to provide the high availability.
>
> The SSO service on the other servers will cache the master secret in memory.
> If the MSS is unavailable for a short time, BizTalk will be able to use this
> cached master secret, and continue processing messages. If the SSO service is
> re-started when the MSS is unavailable, it will not be able to retrieve the
> master secret, and BizTalk will fail to start.
>
> When you install BizTalk on other servers, you should have SSO seelcted for
> install. When you configure BizTalk, you should specify that the SSO service
> will NOT act as the master secret server.
>
> There is also an option to promote any SSO server in the group to MSS, you
> will need the backup of your master secret to do this. It's worth labbing
> with this in a test environemnt to learn how this works, and include the
> process in any disaster recovery policy.
>
>
>
> --
> The Bloggers Guide to BizTalk
> http://geekswithblogs.com/asmith
>
>
>
> "Chris Cichocki" wrote:
>
| |
| WenJun Zhang[msft] 2005-10-24, 10:32 am |
| Hi Chris,
If you need the master secret server be high available, then you need
to build a dediated failover cluster of it. Below is the explaination
in BTS2004 high availability whitepaper:
Highly available.
To provide redundancy for the master secret server, use Windows
Clustering
separate master secret server cluster, or configure the master secret
server on an existing
cluster. The services provided by the master secret server do not
consume many resources,
typically do not affect database functionality or performance when
installed on a database
following figure shows how you can make the master secret server
highly available.
BizTalk Server 2004 Technical Guide for High Availability
http://download.microsoft.com/downl...d8f-4f9a-8349-b
f352fb3d802/High_Availability.exe
The detailed guide about clustering MSS can be found in Biztalk
document.
Best regards,
WenJun Zhang
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader
so that others may learn and benefit from your issue.
========================================
=============
Business-Critical Phone Support (BCPS) provides you with technical
phone support at no charge during critical LAN outages or "business
down" situations. This benefit is available 24 hours a day, 7 days a
week to all Microsoft technology partners in the United States and
Canada.
This and other support options are available here:
BCPS:
https://partner.microsoft.com/US/te...rtoverview/4001
0469
Others:
https://partner.microsoft.com/US/te...upportoverview/
If you are outside the United States, please visit our International
Support page: http://support.microsoft.com/common/international.aspx
========================================
=============
This posting is provided "AS IS" with no warranties, and confers no
rights.
| |
|
| For example:
> BizTalk Base EDI service : .\BTEDIAdmininstrator
> BizTalk Service BizTalk Group : .\BTHostAdministrator
> Rule Engine Update Service : .\BTRuleAdministrator
> Enterprise Single Sign-On Service : .\SSOAdministrator
>
> Also make sure that each belongs to different Windows Group.
>
> Happy trying...
>
> Didi
>
> Bigfoot wrote:
was[vbcol=seagreen]
""WenJun Zhang[msft]"" <v-wzhang@online.microsoft.com> 写入消息新闻
:z#RDEIv0FHA.1148@TK2MSFTNGXA01.phx.gbl...[vbcol=seagreen]
> Hi Chris,
>
> If you need the master secret server be high available, then you need
> to build a dediated failover cluster of it. Below is the explaination
> in BTS2004 high availability whitepaper:
>
> Highly available.
> To provide redundancy for the master secret server, use Windows
> Clustering
> separate master secret server cluster, or configure the master secret
> server on an existing
> cluster. The services provided by the master secret server do not
> consume many resources,
> typically do not affect database functionality or performance when
> installed on a database
> following figure shows how you can make the master secret server
> highly available.
>
> BizTalk Server 2004 Technical Guide for High Availability
> http://download.microsoft.com/downl...d8f-4f9a-8349-b
> f352fb3d802/High_Availability.exe
>
> The detailed guide about clustering MSS can be found in Biztalk
> document.
>
> Best regards,
>
> WenJun Zhang
> Microsoft Online Partner Support
>
> When responding to posts, please "Reply to Group" via your newsreader
> so that others may learn and benefit from your issue.
>
> ========================================
=============
>
> Business-Critical Phone Support (BCPS) provides you with technical
> phone support at no charge during critical LAN outages or "business
> down" situations. This benefit is available 24 hours a day, 7 days a
> week to all Microsoft technology partners in the United States and
> Canada.
>
> This and other support options are available here:
>
> BCPS:
> https://partner.microsoft.com/US/te...rtoverview/4001
> 0469
> Others:
> https://partner.microsoft.com/US/te...upportoverview/
>
> If you are outside the United States, please visit our International
> Support page: http://support.microsoft.com/common/international.aspx
>
> ========================================
=============
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
|
|
|
|
|