nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

IIS based LSDSRT/LSDSAuth and Linux based Teamsite

unlimitself

Hi,

Scenario:

We have our TeamSite installed in Linux and the iw-preview.war acts as the preview server. We have it that way for a longtime now. We have a lot of content in our iw-store.

We recently installed LSDSRT. Our web servers run in IIS and so we are deciding to have LSDSRT run in IIS. The .page we publish might have potential .Net external components and controllers, which also has to work in LSDSAuth. Which means LSDSAuth should also run in IIS.

Below are the Queries

1) Is there a way we can continue to have our TeamSite in Linux but have the LSDSAUTH preview server in IIS. Please advice.
2) Also what are the steps to migrate a Linux based TeamSite completely to a Windows based TeamSite.

- Ravi

Find more posts tagged with

Comments

nipper

You question makes zero sense, there is no LSDSAuth/LSDSRT, but LSCS has RT and Auth modules.

I assume you mean those.

I would plan to move TS from Linux to Win. You will no tbe able to get preview working in SitePublisher, editing may not even work correctly.

Moving from Linux to DOS is possible but not trivial. One cannot list a set of comprehensive steps to do it. I suggest you talk to a consultant (HP or otherwise) for help. Plan on a month or more, depending.

unlimitself

LSDSAuth = iw-preview.net

LSDSRT = LSDS in Runtime

These were the terminologies HP folks used recently in an engagement with us. Lets keep that aside. Not a big thing to discuss. I reconfirm I do not mean LSCS here.

Regarding contacting HP : I have raised a ticket with them and am waiting for a reply.

nipper

OK, I have never heard that terminology before, but no big deal.

Since iwpreview includes LSDS, you really do not need an extra install of LSDS on the TS server, but you would need that for any external (preview or live) servers that need LSDS.

Certainly change the TS server to WIndows. That will make your like much better in the long run, but it will be a hard road.

unlimitself

I might choose to migrate the TeamSite from Linux to Windows.

But I will have to provide a convincing reason to the business. Also I should showcase an already tested best way(steps) of migration. Something like a HP manual that says "Steps to Migrate TeamSite from Linux to Windows". My organization is large/huge and are less likely to take risks.

Rick Poulin

The convincing argument is you'll never be able to preview .NET components within TeamSite itself if you stay on Linux. At best, you'll have to setup a "preview" runtime instance and always deploy incremental changes to it. It's certainly doable but not ideal.

Nobody here will have a silver bullet manual for changing operating systems, not even HP. At best, their professional services (or any consultancy familiar with the product stack, for that matter) would be able to give you best practices, and a general assurance that it's within the realm of the possible. But note two very important things:

* it'll take some time and testing, because it won't work the first time

* you may lose the integrity of your version history

As far as point #2, if you have a system that's been around for a long time and these .NET pieces are part of a revitalization of the implementation, my suggestion is to cut your losses. Make the old system available as a "read only" archive for audit purposes, but only migrate the current version of your content onto the new system. If that's palpable for the users, then you'll save yourself 80% of the risk and effort.

Adam Stoller

Alternatively ... forget about DotNet and use something that will work on Linux ...

(just a thought)

nipper

Even if you fix the preview issue, I am concerned you will have trouble editing DotNet pages on the server.

You could also consider a hybrid approach, use mixed mode (Linux TS and Win Webserver) and use Tomcat/Apache instead of IIS/DotNet

If you have not done a lot of development yet, it may be the easiest and still toss a bone to the people who want Windows servers for runtime

unlimitself

Below is HP Support Reply for TS Migration from Linux to Windows.

Title:
Moving a TeamSite Content Store Across OS Platforms

Synopsis:
This article discusses the options to move a TeamSite content store from Unix to Windows and vice versa.

Details:
It is not possible nor is it supported to move a TeamSite content store from a Unix platform to a Windows platform and vice versa due to incompatible differences in the respective backing store formats. Therefore, the only supported way to migrate across these OS platforms is to copy the content and its associated metadata from a branch workarea on the source server to a corresponding branch workarea on the target server.

This can be done by deploying the content and metadata with OpenDeploy or by using a customized solution. Please contact Support for information regarding custom migration solutions. Note that this will not migrate the version histories of the content, so it is best practice to retain an instance of TeamSite on the original platform for archiving purposes.

nipper

Yep, You cannot move the backingstore, they are incompatible.

That is why I told you that it is a big task. It can be done, but it won't be easy, quick, painless or cheap.

If you need your history then it gets bigger, harder, etc.

3 choices:

Use TOmcat instead of DotNet and push from Linux to WIndows

Purchase a 2nd TS server (running WIndows) for this app

Move everything and taking a great deal of time to do it.

#2 may be your best approach, esp if you have other branches that will be affected when you attempt a move

Adam Stoller

Note that [Support] "retain[ng] an instance of TeamSite on the original platform for archiving purposes" or [@nipper] "Purchase a 2nd TS server (running WIndows) for this app" both, most likely, amount to an additional license...

nipper

ghoti wrote:
Note that [Support] "retain[ng] an instance of TeamSite on the original platform for archiving purposes" or [@nipper] "Purchase a 2nd TS server (running WIndows) for this app" both, most likely, amount to an additional license...

Hense my use of the term Purchase......

unlimitself

Thanks for everyone's response. I will be having a meeting on Moday with my boss to see what we will do. Will keep posted.

nipper

One critical point to find out is what else is on that server and what history must be saved.

OK that was two, but still...