TeamSite on Windows 2000 or Windows 2003

We are currently examing the feasibility of moving TeamSite from the current Solaris environment to a Windows environment.

Prior to Win2k3, we had never considered moving to Windows because we needed a more robust *nix environment. But with the new Server OS, we decided to give it a look.

As the process has moved along, the bean counters are now asking why can't we do it on Windows 2k (to reduce the need to purchase the CALs for Win2k3).

(I have searched these forums and found various tidbits, but) I am wondering if anyone has some thoughts on this debate. With regard to TeamSite, are there any clear advantages to using Win2k3 over Win2k.

Thanks for your time,

Jones

Find more posts tagged with

Comments

Dwayne

We are currently examing the feasibility of moving TeamSite from the current Solaris environment to a Windows environment.

For ****'s sake, why???. I can understand using W2K3 (or W2K) when you're in a MS-only shop. But you've obviously already got Solaris in house. Why switch?

Now, I'll grant that I'm not a big fan of Bill and his family of OS's, so you need to take what I say with a grain of salt. But I think that TeamSite on the Solaris platform is more stable and functional than TeamSite on Windows. One example (and one of the biggest annoyances of running under Windows) - external tasks in a workflow will always be run as the SYSTEM user in Windows, no matter who you list as the task owner. That means that if the external task modified a file (including setting an EA), then the 'last modified by' will show 'SYSTEM' not the real user. No such problem with Solaris.

I also don't believe that there's a good migration methodology in place to move content between Solaris and Windows. That could be very painful.

--

Current project: TS 5.5.2/6.1 W2K

jajtiii

Heh....you sound like my Solaris admin's!

Perhaps we are 'considering' this (just considering it) for the wrong reasons, but here are a smattering of them :

1. 16 Group Solaris Limit (I have seen the 'promises' for this to be removed in 6.5, but I cannot use 'possible' future solutions as a basis for this decision)
2. Permission issues - I cannot count the number of times that an *.ipl file or some other file has had the wrong permissions and caused one of the developers a large amount of time trying to troubleshoot coding issues (before he/she determines it was a simple permission issue)

But, most importantly of all, the fact that most of the really important configuration files lie in locations that our Solaris Admin's keep secure (and off limits to us) because of daemons running at root level or whatnot. I don't even have direct access (except 'read') to the iw.cfg file, even on our test environment.

Therefore, we may be willing to sacrifice some of the strengths of a UNIX os for benefits we can gain in actually admin'ing the app.

Migrateduser

With all due respect to you and your team, how would a developer that's worth his or her $0.02 repeatedly spend so much time with file permissions, of all things?

Just wondering.

I agree with you on #1, though. I've had problems with that, too, on Solaris and AIX.

Perhaps you can set up a branch that deploys the configuration files to where they need to be? That would take a bit of time, but far less than migrating your stuff over to the Windows platform, it would seem to me.

Dave

jajtiii

We could definitely do what you suggest. OpenDeploy pretty much takes control of the box it sits on (even when just a receiver).

I have never mentioned it to the Solaris Admins (as, anyone who knows a Solaris admin will tell you they are the stereotypical IT pin-head and would surely spout off about 200 Unix things I could care less about - although it clearly gives them some measure of pride to hear it come out of their mouths=), but will go ahead and do so just to see what they say.

Regardless, back to my original question...

Windows 2000 enough?

I guess I should put it another way. If I were a Wintel shop only, is Win2k enough for 200 end users deploying through 50 branches (internet and intranet)?

Migrateduser

Certainly seems to be -- I've worked on both W2K and W2K3. I can't say I've had any more problems on one over the other... notice, I didn't say that I didn't have problems at all.

Anyway, are you actually going to TELL your Solaris admin about the OD strategy?? If they're so stereotypical, they might just get territorial about their precious system files (even though he could probably give a **** about TS files).

Dave

jajtiii

Ha...well, you read my mind.

After reading and considering your post, I went ahead and got my colleague, a wiz at OD, to agree to get together next week to plan this thing. We'll run it on our test box and then advise them of it when we want to move to production....

Needless to say, there will be a complete uproar, but if we have already proven we can do it (plus, I'll reference you as a 'TeamSite Pro on Devnet advised...'

, we may be able to get it through the door.

There is not enough space in the dB table for this forum for me to type out the intricacies between the multiple layers we have with regard to TeamSite.

All I can say is that what most people on this forum take for granted, I have to do a change management record, get a few approvals and then I actually have to send THE ADDITIONAL CODE (so that the Solaris admin can add it to the existing file....yes, that creates room for all manner of error) to be included.

Well, thanks for the input on both subjects. You might get me fired, but at least I see light at the end of the rainbow.

Migrateduser

Well, it's just that I've seen this implemented in other environments (although mostly on Windows, but for the same reasons) and if the users modifying the content are careful enough, the workflow and OD are set up well, it's a completely viable way to screw with the TS configs.

Maybe it's even better. C'mon, who among us saves a backup EVERY SINGLE TIME when modifying a config file, regardless of how minor the change? Well, okay, I admit I don't :-)

Dave

jajtiii

It is my opinion that we should be able to screw up the TS config files, on the development box.

There is no better way to learn then through fire and blood. Plus, it will give us the ability to test things the way they should be tested (which can require multiple tweaks), instead of sending emails and having to rely on someone else to exactly replicate your requested changes.

Alas, as time goes on, I must admit that I don't save backups as much as I used to. Versions to the rescue.

Migrateduser

Exactly... in TS, just recover a previous version and push it through workflow. We're on the same page :-)

Dave

brandon1

Using Teamsite/OD to version and push Teamsite config/code files to TeamSite environments is in use at my current client, and has so far been a time/money saver!

Current Project: Content Services implementation

Adam Stoller

With regard to access to iw.cfg - I believe you can symlink /etc/iw.cfg to IWHOME/etc/iw.cfg - and then as long as you have access to IWHOME/etc you can edit iw.cfg to your heart's content...

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

smenon

The TeamSite Groups feature is being delivered as part of the TeamSite 6.5 release which is still on track for release on October 28, 2004. This feature will specifically allow you to create TeamSite Groups that need not be OS Groups enabling you to overcome the 16-group limitation on Solaris.

There was failry large discussion about this feature on devnet about 2 months ago.. Here is the link to that thread..

http://devnet.interwoven.com/forums/cgi-bin/showflat.pl?Cat=&Board=PRODUCTS_TEAMSITE&Number=32733&page=&view=&sb=&o=&part=4&vc=1

thanks

--Sunil Menon
Product Manager
Interwoven, Inc.