10-07-04 01:46 AM
Paul, we are working with BTS 2004, SQL Server 2000 SP3 and our primary
servers for BTS are 2003 Ent.
Our workstations for development, however, are predominantly Win2K Pro. Now
the good stuff...
I was challenged to setup HWS and get it working on Win2KPro.
Well... I could not.
I walked through Lab 12 for HWS - initially on a 2K Pro workstation. When it
comes time to connect to http://localhost/hwsservice, it continues to fail
indicating that it cannot resolve the line 107 setup - the parameters for th
e
login / password of the processmodel settings for Machine / AutoGenerate
settings from the registry.
I worked on this for more than 2 hours trying to resolve security / settings
to allow the ASPNET account (I'm assuming this is the problem) to access the
web service.
Interestingly, and this is MOST interesting: I can copy the source files to
the 2003 server - compile, deploy and shazaam, it works; did the same on an
XP pro workstation that interfaces with a 2003 server running the BTS 2004
and it too, worked perfectly.
What's going on with Win 2K Pro that's so different security-wise? I really
need to get this resolved.
You can also email me at work (My Passport account is not accessible from
work) at hamilton"dot"michae"at"towerautomotive"dot"com.
Thanks...
"Paul Davidson" wrote:
> RPC is more secure/locked down on 2003 than 2000 - but functionally your
> cluster will be the same as 2k3. There's a couple built-in accounts that
> 2000 doesn't have that 2003 does(NETWORK SERVICE, LOCAL SERVICE). It woul
d
> be best to use purposed domain accounts for services instead of built-in
> ones...
> --------------------
> Thread-Topic: Can/Should BTS04 be run on a mixed W2k/W2k3 server environme
nt
> thread-index: AcSFItp2mUvZPUeqSS+U1niMUn1DUg==
> X-WBNR-Posting-Host: 204.74.160.11
> From: "examnotes" <DavidSelim@discussions.microsoft.com
>
> Subject: Can/Should BTS04 be run on a mixed W2k/W2k3 server environment
> Date: Wed, 18 Aug 2004 05:57:01 -0700
> Lines: 33
> Message-ID: <6B12AAFC-140D-4E12-B24A-3973F33EC7C8@microsoft.com>
> MIME-Version: 1.0
> Content-Type: text/plain;
> charset="Utf-8"
> Content-Transfer-Encoding: 7bit
> X-Newsreader: Microsoft CDO for Windows 2000
> Content-Class: urn:content-classes:message
> Importance: normal
> Priority: normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
> Newsgroups: microsoft.public.biztalk.setup
> NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
> Path: cpmsftngxa06.phx.gbl!TK2MSFTNGXA03.phx.gbl
> Xref: cpmsftngxa06.phx.gbl microsoft.public.biztalk.setup:4420
> X-Tomcat-NG: microsoft.public.biztalk.setup
>
> We are in the process of setting up a BizTalk 2004 server environment. It'
s
> first use in our enterprise will be internal application integration for
> one
> specific area, but from there its role is exptected to expand throughout
> the
> business.
>
> Our large lab environment is currently set up with two servers dedicated t
o
> the BizTalk 2004 runtime, an additional server running as the SSO Master
> Secret server, and one SQL server. All server OS's are currently at the
> Windows 2003 Server level.
>
> The proposed production environment will mirror the lab setup above, with
> the at least one addition BizTalk 2004 server, and the SQL servers and SSO
> Master Secret servers being clustered.
>
> Now the project leader has asked if there will be any problems caused if
> the
> SSO Master Secret server cluster in production can be run on Windows 2000
> Advanced Server while the BizTalk runtime servers will remain on Windows
> Server 2003. The reason is they have another vendor's software package tha
t
> should be run in a clustered environment, and this software is not
> certified
> to run on W2k3, and they want to be able to leverage the SSO Master Secret
> server cluster hardware/OS licenses to save some money.
>
> While nothing I've read about BTS 04 specifically states this type of OS
> version split cannot be done, is it a wise course of action? What potentia
l
> pitfalls will be brought to light if we follow this road? What can be done
> to
> alleviate some potential issues if this change is made?
>
> Our current testing environment has been pretty bulletproof, and making
> such
> a change just a few months before the planned production rollout scares me
> just a bit.
>
> Thanks in advance,
> Dave
>
[ Post a follow-up to this message ]
| 
