Hi,
IHAC, who uses Sun Calendar Server 6.0 -
1. Can we upgrade to the latest 2005Q4 (on the same host) or
2. Can we export the required data/configuration and import it to the new server with 2005Q5 installed
In both the cases, we will be using the DS 5.2p4 in schema I
Regards,
Deepak
Hi,
> IHAC, who uses Sun Calendar Server 6.0 -
What version exactly? Calendar server 6 covers a wide range of versions.
> 1. Can we upgrade to the latest 2005Q4 (on the same
> host) or
Depends on the exact version you are coming from. I suggest you read the manuals with regards to upgrades for calendar server.
http://docs.sun.com/source/819-2331/calendarSvr.html
> 2. Can we export the required data/configuration and
> import it to the new server with 2005Q5 installed
I don't see why not. Of course you would need to test this thoroughly. I am assuming of course that the 'new server' is the same platform (sparc->sparc or x86->x86). This is usually the safest approach since you can test this prior to running the production migration.
> In both the cases, we will be using the DS 5.2p4 in
> schema I
Shouldn't be an issue.
Shane.
> Hi,
>
> > IHAC, who uses Sun Calendar Server 6.0 -
>
> What version exactly? Calendar server 6 covers a wide
> range of versions.
We have
Sun Calendar Server V6.0 (Rev. 2003.11.14.18.12.58)
>
> 1. Can we upgrade to the latest 2005Q4 (on the same
> host) or
>
> Depends on the exact version you are coming from. I
> suggest you read the manuals with regards to upgrades
> for calendar server.
>
> http://docs.sun.com/source/819-2331/calendarSvr.html
>
> > 2. Can we export the required data/configuration
> and
> > import it to the new server with 2005Q5 installed
>
> I don't see why not. Of course you would need to test
> this thoroughly. I am assuming of course that the
> 'new server' is the same platform (sparc->sparc or
> x86->x86). This is usually the safest approach since
> you can test this prior to running the production
> migration.
It will be Sparc-Sparc
>
> > In both the cases, we will be using the DS 5.2p4
> in
> > schema I
>
> Shouldn't be an issue.
>
> Shane.
