forgotten GENERATED passwords ?

2007-05-17 Thread goc

hi, now thats interesting ...
last night all backups from one of our servers went MISSED
because the GENERATED passwords got lost somewhere,
the passwords were not changed, the password retention is
set to  days, PASSWORDACCESS 100% on GENERATE
... so i really don't know what happened ...

the day before everything was okay, dsmcad's were not restarted
, i saw this couple of years ago but i do not remember the details ...

in all logs the message was the same :

05/17/07   08:14:13 Scheduler has been started by Dsmcad.
05/17/07   08:14:13 Querying server for next scheduled event.
05/17/07   08:14:13 Node Name: NODE_NAME
05/17/07   08:14:13 ANS2050E TSM needs to prompt for the password but
cannot prompt  because the process is running in the background.
05/17/07   08:14:13 ANS2050E TSM needs to prompt for the password but
cannot prompt  because the process is running in the background.
05/17/07   08:14:13 ANS1029E Communication with the  TSM server is lost.
05/17/07   08:14:13 Scheduler has been stopped.

if anyone has a clue it will be greatly appreciated, thanks

TSM 5.3.4 on AIX 5.2
clients AIX 5.3.4 and HP-UX 5.3.4


Re: forgotten GENERATED passwords ?

2007-05-17 Thread Richard Sims

On May 17, 2007, at 3:45 AM, goc wrote:


hi, now thats interesting ...
last night all backups from one of our servers went MISSED
because the GENERATED passwords got lost somewhere,
the passwords were not changed, the password retention is
set to  days, PASSWORDACCESS 100% on GENERATE
... so i really don't know what happened ...


You don't say what investigation you've done to pursue this.

Did anyone introduce or change the PASSWORDDIR client option?
If no PASSWORDDIR option in effect, is there a TSM.PWD file
in directory /etc/security/adsm/, the default location for the
password file?  If not, the mtime timestamp on the directory
will show when the contents of the directory changed and thus
narrow down whatever event occurred.  (Did some ambitious
system administrator do file system housekeeping?)
Is there a TSM.PWD file there, but zero length?  That would
suggest that an attempt was made to change the password at a
time when the file system was full.
In poring over the client schedule and error logs, and TSM
server Activity Log, do you find any evidence of a problem?
Is there in any way a change to the identity of the client,
in OS or TSM terms, such that that identity is inconsistent
with the nodename in the TSM password file?

   Richard Sims


Re: Server migration

2007-05-17 Thread Haberstroh, Debbie (IT)
Steven and Larry,

One of the options we are looking at is to restore the database to both sides 
of the new server and remove the nodes that are not moving to the server, 
essentially splitting the database.  This was a high level recommendation from 
a consultant.  Part of the problem with this method is the copypool is shared 
by the majority of the nodes.  I will probably need to create a new storage 
pool heirarchy and move some of the nodedata to this before we go to the new 
server.  We were then going to setup the nodes to backup to their respective 
new servers.  Finally, I would need to migrate the remaining data that was 
backed up since the time of the database backup that we used for the restore.  
When I do the final export/import, does it go to the disk storage pool assigned 
to the node or does it go to tape?  I know there are multiple options to doing 
this and we are still in the research mode.  I will go through the archive and 
look for past suggestions and recommendations on this.  Thanks.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Steven Harris
Sent: Wednesday, May 16, 2007 7:57 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Server migration


Debbie,

I'd suggest that you move the existing TSM Server  holus-bolus to the
new machine if you can ,  as Larry has described, and  then do the split.

The reason is that server-to-server export  between TSM Servers on the
same machine will be many times more efficient than  across an external
network.

There is no escaping it - the server to server move of each node will
require a copy from tape to server1 / across to server 2/ back on to
tape.  The only other option is to just start backing up the nodes to
the new server and at some point delete them from the old.  There are
lots of posts on this topic in the archives.

Regards

Steve
Steven Harris
AIX and TSM Admin Brisbane Australia
Moving to Sydney soon and Still no job offers

Lawrence Clark wrote:
 The current status of everything is kept in the database and some config
 files:
 /usr/tivoli/tsm/server/bin/dsmserv.opt\
 /home/root/tsmfiles/devconfig.info  \
 /home/root/tsmfiles/volhistory.info

 So if the data is all on cartridge when you migrate and you create disk
 based storage pools and db vols on the target side that match the
 source, and move those config fies to equivalent places, you should be
 able to backup the db on one side, restore on the other. Have to move
 the tape library over. And I'm talking TSM on AIX.


 [EMAIL PROTECTED] 05/16/07 3:35 PM 

 I am looking at different options to migrate data from our current
 server, version 5.3.3 to a second TSM server, 5.3.5.  Actually the new
 server will have 2 instances of TSM running and I will need to divide
 the clients between the 2, the old one will be retired.  I have several
 different paths that I can follow and am trying to get a little more
 detailed information so I know we can decide on which method to use.

 If I want to migrate server-to-server does the data go into the disk
 storage pool for the node first and then copy off to tape?
 I am using the same library and tapes for the new server that the
 current server uses, will the new server keep the tapes I already have
 for the node or will it write new ones?

 I know there is a lot more to this, I'm just trying to find out how
 some of the processes work.

 Debbie Haberstroh
 Server Administration
 Northrop Grumman Information Technology
 Commercial, State  Local (CSL)
 972-946-5639


 The information contained in this electronic message and any attachments to 
 this message are intended for the exclusive use of the addressee(s) and may 
 contain information that is confidential, privileged, and/or otherwise exempt 
 from disclosure under applicable law.  If this electronic message is from an 
 attorney or someone in the Legal Department, it may also contain confidential 
 attorney-client communications which may be privileged and protected from 
 disclosure.  If you are not the intended recipient, be advised that you have 
 received this message in error and that any use, dissemination, forwarding, 
 printing, or copying is strictly prohibited.  Please notify the New York 
 State Thruway Authority immediately by either responding to this e-mail or 
 calling (518) 436-2700, and destroy all copies of this message and any 
 attachments.





Re: forgotten GENERATED passwords ?

2007-05-17 Thread goc

hi, thanks for input, some answers ...

- no, no one changed the PASSWORDDIR client option, in fact i had it
only in four dsm.sys stanzas

- for HP-UX TSM.PWD location is /etc/adsm , unfortunately i generated
the passwords again as soon as possible since my arch logs backups
where failing so my time stamps are fresh

- about evidence, absolutely none whatsoever was found, i digged the
whole actlog in that period which is from 9:00 till 16:32 as noticed
in dsmsched logs

- there is no way to change the identity of the client, only i can do that :-)

- what i noticed is that unfortunately it happened on other server as
well, actually we are talking here about 4 node HP-UX cluster with
oracle databases, my scrips checks which DB is on what node and
starts,stops, kills appropriate dsmcad process

- so, it happened only on 2 servers, im 95% sure ... checking further

thanks again


On 5/17/07, Richard Sims [EMAIL PROTECTED] wrote:

On May 17, 2007, at 3:45 AM, goc wrote:

 hi, now thats interesting ...
 last night all backups from one of our servers went MISSED
 because the GENERATED passwords got lost somewhere,
 the passwords were not changed, the password retention is
 set to  days, PASSWORDACCESS 100% on GENERATE
 ... so i really don't know what happened ...

You don't say what investigation you've done to pursue this.

Did anyone introduce or change the PASSWORDDIR client option?
If no PASSWORDDIR option in effect, is there a TSM.PWD file
in directory /etc/security/adsm/, the default location for the
password file?  If not, the mtime timestamp on the directory
will show when the contents of the directory changed and thus
narrow down whatever event occurred.  (Did some ambitious
system administrator do file system housekeeping?)
Is there a TSM.PWD file there, but zero length?  That would
suggest that an attempt was made to change the password at a
time when the file system was full.
In poring over the client schedule and error logs, and TSM
server Activity Log, do you find any evidence of a problem?
Is there in any way a change to the identity of the client,
in OS or TSM terms, such that that identity is inconsistent
with the nodename in the TSM password file?

Richard Sims



Re: Server migration

2007-05-17 Thread Allen S. Rout
 [EMAIL PROTECTED] 05/16/07 3:35 PM 

 I am looking at different options to migrate data from our current
 server, version 5.3.3 to a second TSM server, 5.3.5.  Actually the new
 server will have 2 instances of TSM running and I will need to divide
 the clients between the 2, the old one will be retired.  I have several
 different paths that I can follow and am trying to get a little more
 detailed information so I know we can decide on which method to use.


I set about attempting to catalog ways of getting nodes from one
server to another, N years ago.

http://open-systems.ufl.edu/services/NSAM/whitepapers/50ways.html

I encourage you to look over it: please be encouraged to throw
tomatoes or otherwise critique.


- Allen S. Rout


Re: Server migration

2007-05-17 Thread Allen S. Rout
 On Thu, 17 May 2007 10:56:58 +1000, Steven Harris [EMAIL PROTECTED] said:

 There is no escaping it - the server to server move of each node will
 require a copy from tape to server1 / across to server 2/ back on to
 tape.  The only other option is to just start backing up the nodes to
 the new server and at some point delete them from the old.  There are
 lots of posts on this topic in the archives.


If you are scrupulously careful about making sure no physical media
holds both some data for target server A and some for target server B,
you can just restore the source DB twice, and

 very.

  very.

   very

carefully delete the unwanted nodes from each target server.


- Allen S. Rout


Using different Mangement Classes

2007-05-17 Thread Dennis, Melburn IT7
I am wanting to have 1 client (windows) backup to a different management
class in the same domain.  Below is my original dsm.opt file:
 
 
NODENAME W72C-C5SK9B1
TCPSERVERADDRESS USORL00T483
ERRORLOGRETENTION 14 D
SCHEDLOGRETENTION 7 D
MEMORYEFFICIENTBACKUP YES
PASSWORDACCESS GENERATE
DOMAIN ALL-LOCAL
 
EXCLUDE.BACKUP ?:\...\EA DATA.SF
EXCLUDE.BACKUP C:\...\system32\Perflib*.dat
EXCLUDE.BACKUP C:\...\system32\dhcp\...\*
 
INCLUDE.BACKUP C:\...\system32\dhcp\backup\...\*
 
EXCLUDE ?:\WINNT\system32\dhcp\backup\new\*.log
EXCLUDE ?:\...\pagefile.sys
EXCLUDE ?:\...\*.par
EXCLUDE ?:\...\*.dmp
EXCLUDE ?:\...\*.tmp  
EXCLUDE ?:\...\~*   
EXCLUDE ?:\...\*.hlp
EXCLUDE ?:\...\*.mdm
EXCLUDE ?:\...\notes.rip
EXCLUDE ?:\...\*.nsf
EXCLUDE ?:\...\*.ntf
EXCLUDE C:\WINNT\security\edb.log
 
EXCLUDE.DIR ?:\DELL
EXCLUDE.DIR ?:\apps
EXCLUDE.DIR ?:\System Volume Information
EXCLUDE.DIR ?:\Recycle*
EXCLUDE.DIR ?:\...\*.ft
EXCLUDE.DIR c:\TSM
EXCLUDE.DIR C:\adsm.sys
EXCLUDE.DIR c:\Source
EXCLUDE.DIR ?:\spaceman
EXCLUDE.DIR ?:\i386
EXCLUDE.DIR ?:\...\tsm-restore*
EXCLUDE.DIR ?:\mssql\data  
EXCLUDE.DIR ?:\temp
EXCLUDE.DIR ?:\...\$NtUninstall*
EXCLUDE.DIR ?:\found.00?
EXCLUDE.DIR ?:\lsdp
EXCLUDE.DIR ?:\catupdate
EXCLUDE.DIR ?:\sw-pool
 
EXCLUDE.DIR C:\Program Files\Trend Micro\Control
Manager\AU_Temp\3680_3872\AU_Down\Pattern
EXCLUDE.DIR C:\WINNT\system32\spool\PRINTERS
EXCLUDE.DIR ?:\...\*.ft
EXCLUDE.DIR C:\WINNT\SoftwareDistribution
 
EXCLUDE.DIR ?:\SMS
EXCLUDE.DIR ?:\SMS_CCM
EXCLUDE.DIR ?:\SMSDATA
EXCLUDE.DIR ?:\CAP_*
EXCLUDE.DIR ?:\tsmlvsacache
 
 
It is my assumption from reading the client guide that I can just add
the following line to the top of the include/exclude list and it will
cause all the files that backup to use the non-default management class:

INLCUDE * NEW_MC
 
My only concern is the 1 include statement I have in the above list.
Will I have to add the management class to that line as well? Or will
the single include statement at the top cover everything.

INCLUDE.BACKUP C:\...\system32\dhcp\backup\...\* NEW_MC

 
Mel Dennis
Backup Systems Engineer
 
Siemens IT Solutions and Services, Inc.
PGST Data Center Operations
4400 Alafaya Trail
MC Q1-108
Orlando, FL 32826
Tel.: 407-736-2360
Mob: 321-356-9366
Fax: 407-243-0260
mailto:[EMAIL PROTECTED]
www.usa.siemens.com/it-solutions


Re: Using different Mangement Classes

2007-05-17 Thread Andrew Raibeck
Hi Dennis,

INCLUDE/EXCLUDE processing stops when there is a match found for the file
specification. So if you want the new management class to be used by the
existing INCLUDE.BACKUP file specification, you will need to append the
management class name to the end of that statements, too.

Best regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED]
Internet e-mail: [EMAIL PROTECTED]

IBM Tivoli Storage Manager support web page:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html

The only dumb question is the one that goes unasked.
The command line is your friend.
Good enough is the enemy of excellence.

ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 2007-05-17
08:03:31:

 I am wanting to have 1 client (windows) backup to a different management
 class in the same domain.  Below is my original dsm.opt file:


NODENAME W72C-C5SK9B1
TCPSERVERADDRESS USORL00T483
ERRORLOGRETENTION 14 D
SCHEDLOGRETENTION 7 D
MEMORYEFFICIENTBACKUP YES
PASSWORDACCESS GENERATE
DOMAIN ALL-LOCAL

EXCLUDE.BACKUP ?:\...\EA DATA.SF
EXCLUDE.BACKUP C:\...\system32\Perflib*.dat
EXCLUDE.BACKUP C:\...\system32\dhcp\...\*

INCLUDE.BACKUP C:\...\system32\dhcp\backup\...\*

EXCLUDE ?:\WINNT\system32\dhcp\backup\new\*.log
EXCLUDE ?:\...\pagefile.sys
EXCLUDE ?:\...\*.par
EXCLUDE ?:\...\*.dmp
EXCLUDE ?:\...\*.tmp
EXCLUDE ?:\...\~*
EXCLUDE ?:\...\*.hlp
EXCLUDE ?:\...\*.mdm
EXCLUDE ?:\...\notes.rip
EXCLUDE ?:\...\*.nsf
EXCLUDE ?:\...\*.ntf
EXCLUDE C:\WINNT\security\edb.log

EXCLUDE.DIR ?:\DELL
EXCLUDE.DIR ?:\apps
EXCLUDE.DIR ?:\System Volume Information
EXCLUDE.DIR ?:\Recycle*
EXCLUDE.DIR ?:\...\*.ft
EXCLUDE.DIR c:\TSM
EXCLUDE.DIR C:\adsm.sys
EXCLUDE.DIR c:\Source
EXCLUDE.DIR ?:\spaceman
EXCLUDE.DIR ?:\i386
EXCLUDE.DIR ?:\...\tsm-restore*
EXCLUDE.DIR ?:\mssql\data
EXCLUDE.DIR ?:\temp
EXCLUDE.DIR ?:\...\$NtUninstall*
EXCLUDE.DIR ?:\found.00?
EXCLUDE.DIR ?:\lsdp
EXCLUDE.DIR ?:\catupdate
EXCLUDE.DIR ?:\sw-pool

EXCLUDE.DIR C:\Program Files\Trend Micro\Control
 Manager\AU_Temp\3680_3872\AU_Down\Pattern
EXCLUDE.DIR C:\WINNT\system32\spool\PRINTERS
EXCLUDE.DIR ?:\...\*.ft
EXCLUDE.DIR C:\WINNT\SoftwareDistribution

EXCLUDE.DIR ?:\SMS
EXCLUDE.DIR ?:\SMS_CCM
EXCLUDE.DIR ?:\SMSDATA
EXCLUDE.DIR ?:\CAP_*
EXCLUDE.DIR ?:\tsmlvsacache


 It is my assumption from reading the client guide that I can just add
 the following line to the top of the include/exclude list and it will
 cause all the files that backup to use the non-default management class:

INLCUDE * NEW_MC

 My only concern is the 1 include statement I have in the above list.
 Will I have to add the management class to that line as well? Or will
 the single include statement at the top cover everything.

INCLUDE.BACKUP C:\...\system32\dhcp\backup\...\* NEW_MC


 Mel Dennis
 Backup Systems Engineer

 Siemens IT Solutions and Services, Inc.
 PGST Data Center Operations
 4400 Alafaya Trail
 MC Q1-108
 Orlando, FL 32826
 Tel.: 407-736-2360
 Mob: 321-356-9366
 Fax: 407-243-0260
 mailto:[EMAIL PROTECTED]
 www.usa.siemens.com/it-solutions


Re: 'define machine' for DRM, is it necessary?

2007-05-17 Thread Prather, Wanda
No, you don't have to do the define machine.
 
I think it was supposed to be a long-ago way to save information on the TSm 
server about what was necessary to get critical clients up and running again 
(and in what order), so that once you had the TSm data base restored, all your 
recovery instructions are there.
 
But in practice, it's too hard to keep the info current and updated, IMHO.
 
Easier just to put the doc in a file, and save that in a group space where 
everybody can keep it updated.  If you know where it is, you can always restore 
it first thing.  Or email it to yourself.  Or FTP it somewhere.  Or have all 
managers keep a paper copy in their car.  Whatever.  I think it's more 
important to keep it current, than to keep it in TSM.
 
 
 



From: ADSM: Dist Stor Manager on behalf of Bell, Charles (Chip)
Sent: Wed 5/16/2007 10:47 AM
To: ADSM-L@VM.MARIST.EDU
Subject: 'define machine' for DRM, is it necessary?



If what you see below is what I have set up for DRM, do I have to set up
machines and associations for my TSM server and clients in TSM? Will this
info not be brought back after mksysb and TSM DB restore (using DRM)?



tsm: TSMq drmstatus



Recovery Plan Prefix: /drm/plan/tsm

Plan Instructions Prefix: /drm/instruction/tsm

Replacement Volume Postfix: @

Primary Storage Pools: DATABASE_MANAGE DATABASE_MIGRATE

DATABASE_MIGRATE_LTO2 DATABASE_VTL_3592

EMAGEON2_MIGRATE EMAGEON_MANAGE

EMAGEON_MIGRATE EXCHANGE_MIGRATE

EXCHANGE_VTL_3592 INFORMIX_MANAGE

INTEL_MIGRATE META_DISK META_MIGRATE

SANDIRECT_MIGRATE SPACEMGPOOL UNIX_MANAGE

UNIX_MIGRATE

Copy Storage Pools: DATABASE_OFFSITE DATABASE_OFFSITE_LTO2

EMAGEON2_OFFSITE EMAGEON_COPY

EXCHANGE_OFFSITE INTEL_OFFSITE

META_OFFSITE SANDIRECT_OFFSITE

UNIX_OFFSITE

Not Mountable Location Name: Waiting for Courier

Courier Name: Iron Mountain

Vault Site Name: Iron Mountain

DB Backup Series Expiration Days: 5 Day(s)

Recovery Plan File Expiration Days: 14 Day(s)

Check Label?: No

Process FILE Device Type?: No

Command File Name:



God bless you!!!

Chip Bell
Network Engineer I
IBM Tivoli Certified Deployment Professional

Baptist Health System
Birmingham, AL







-
Confidentiality Notice:
The information contained in this email message is privileged and
confidential information and intended only for the use of the
individual or entity named in the address. If you are not the
intended recipient, you are hereby notified that any dissemination,
distribution, or copying of this information is strictly
prohibited. If you received this information in error, please
notify the sender and delete this information from your computer
and retain no copies of any of this information.


Re: 'Q LIC' showing TSM Extended Edition not in use?

2007-05-17 Thread Prather, Wanda
 
why am I seeing the output below, though I am using DRM? 
 
There is no longer a separate license for DRM.  (WHY it displays the way it 
does, who knows - the marketing changes for TSM licensing have galloped far 
ahead of the server code.)  If you enter HELP REGISTER LICENSE, you'll see 
there are only 2 licenses to register for TSM 5.3.
 
Will this affect a DRM test in August, 
 
 
NO.





tsm: TSMq lic



Last License Audit: 05/16/07   00:01:07

Is Tivoli Storage Manager for Data Retention in use ?: No

Is Tivoli Storage Manager for Data Retention licensed ?: No

Is Tivoli Storage Manager Basic Edition in use: Yes

Is Tivoli Storage Manager Basic Edition licensed: Yes

Is Tivoli Storage Manager Extended Edition in use: No

Is Tivoli Storage Manager Extended Edition licensed: Yes

Server License Compliance: Valid





God bless you!!!

Chip Bell
Network Engineer I
IBM Tivoli Certified Deployment Professional (ITSM 5.2)
Baptist Health System
Birmingham, AL
Office (205) 715-5106
Pager (205) 817-0357
Home (256) 739-0947
Cell (256) 347-7294





-
Confidentiality Notice:
The information contained in this email message is privileged and
confidential information and intended only for the use of the
individual or entity named in the address. If you are not the
intended recipient, you are hereby notified that any dissemination,
distribution, or copying of this information is strictly
prohibited. If you received this information in error, please
notify the sender and delete this information from your computer
and retain no copies of any of this information.


Re: Server migration

2007-05-17 Thread Prather, Wanda
And, 
I'd guess that doing MOVE NODEDATA on the source server to make sure you have 
them segregated (preferably into a different pool) would be faster and cleaner 
than server-to-server moves.
 
Probably.   Just another idea.
 
W



From: ADSM: Dist Stor Manager on behalf of Allen S. Rout
Sent: Thu 5/17/2007 10:55 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Server migration



 On Thu, 17 May 2007 10:56:58 +1000, Steven Harris [EMAIL PROTECTED] said:

 There is no escaping it - the server to server move of each node will
 require a copy from tape to server1 / across to server 2/ back on to
 tape.  The only other option is to just start backing up the nodes to
 the new server and at some point delete them from the old.  There are
 lots of posts on this topic in the archives.


If you are scrupulously careful about making sure no physical media
holds both some data for target server A and some for target server B,
you can just restore the source DB twice, and

 very.

  very.

   very

carefully delete the unwanted nodes from each target server.


- Allen S. Rout


Re: Server migration

2007-05-17 Thread Haberstroh, Debbie (IT)
I will definately take the time to read this, thanks.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Allen S. Rout
Sent: Thursday, May 17, 2007 9:52 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Server migration


 [EMAIL PROTECTED] 05/16/07 3:35 PM 

 I am looking at different options to migrate data from our current
 server, version 5.3.3 to a second TSM server, 5.3.5.  Actually the new
 server will have 2 instances of TSM running and I will need to divide
 the clients between the 2, the old one will be retired.  I have several
 different paths that I can follow and am trying to get a little more
 detailed information so I know we can decide on which method to use.


I set about attempting to catalog ways of getting nodes from one
server to another, N years ago.

http://open-systems.ufl.edu/services/NSAM/whitepapers/50ways.html

I encourage you to look over it: please be encouraged to throw
tomatoes or otherwise critique.


- Allen S. Rout


Re: Server migration

2007-05-17 Thread Haberstroh, Debbie (IT)
That's what my plan would be.  Hopefully I have enough time to do the moves 
before I need to setup the new server.  I am waiting on disk storage for the 
new diskpools before I can start.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Prather, Wanda
Sent: Thursday, May 17, 2007 11:42 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Server migration


And, 
I'd guess that doing MOVE NODEDATA on the source server to make sure you have 
them segregated (preferably into a different pool) would be faster and cleaner 
than server-to-server moves.
 
Probably.   Just another idea.
 
W



From: ADSM: Dist Stor Manager on behalf of Allen S. Rout
Sent: Thu 5/17/2007 10:55 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Server migration



 On Thu, 17 May 2007 10:56:58 +1000, Steven Harris [EMAIL PROTECTED] said:

 There is no escaping it - the server to server move of each node will
 require a copy from tape to server1 / across to server 2/ back on to
 tape.  The only other option is to just start backing up the nodes to
 the new server and at some point delete them from the old.  There are
 lots of posts on this topic in the archives.


If you are scrupulously careful about making sure no physical media
holds both some data for target server A and some for target server B,
you can just restore the source DB twice, and

 very.

  very.

   very

carefully delete the unwanted nodes from each target server.


- Allen S. Rout


Re: 'Q LIC' showing TSM Extended Edition not in use?

2007-05-17 Thread Bell, Charles (Chip)
Thanks for your reply! I have to tell you that I was confused seeing that,
considering Extended Edition is what it is primarily because of having DRM as
a component. And we use it, but 'q lic' showed Extended Edition not in
use(?). SO you are saying that is a misprint?  Again, thanks!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Prather, Wanda
Sent: Thursday, May 17, 2007 11:39 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] 'Q LIC' showing TSM Extended Edition not in use?

 
why am I seeing the output below, though I am using DRM? 
 
There is no longer a separate license for DRM.  (WHY it displays the way it
does, who knows - the marketing changes for TSM licensing have galloped far
ahead of the server code.)  If you enter HELP REGISTER LICENSE, you'll see
there are only 2 licenses to register for TSM 5.3.
 
Will this affect a DRM test in August, 
 
 
NO.





tsm: TSMq lic



Last License Audit: 05/16/07   00:01:07

Is Tivoli Storage Manager for Data Retention in use ?: No

Is Tivoli Storage Manager for Data Retention licensed ?: No

Is Tivoli Storage Manager Basic Edition in use: Yes

Is Tivoli Storage Manager Basic Edition licensed: Yes

Is Tivoli Storage Manager Extended Edition in use: No

Is Tivoli Storage Manager Extended Edition licensed: Yes

Server License Compliance: Valid





God bless you!!!

Chip Bell
Network Engineer I
IBM Tivoli Certified Deployment Professional (ITSM 5.2)
Baptist Health System
Birmingham, AL
Office (205) 715-5106
Pager (205) 817-0357
Home (256) 739-0947
Cell (256) 347-7294





-
Confidentiality Notice:
The information contained in this email message is privileged and
confidential information and intended only for the use of the
individual or entity named in the address. If you are not the
intended recipient, you are hereby notified that any dissemination,
distribution, or copying of this information is strictly
prohibited. If you received this information in error, please
notify the sender and delete this information from your computer
and retain no copies of any of this information.


Re: 'define machine' for DRM, is it necessary?

2007-05-17 Thread Bell, Charles (Chip)
Agreed. The docs word in a way to make you believe you need to do it. Thanks!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Prather, Wanda
Sent: Thursday, May 17, 2007 11:37 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] 'define machine' for DRM, is it necessary?

No, you don't have to do the define machine.
 
I think it was supposed to be a long-ago way to save information on the TSm
server about what was necessary to get critical clients up and running again
(and in what order), so that once you had the TSm data base restored, all
your recovery instructions are there.
 
But in practice, it's too hard to keep the info current and updated, IMHO.
 
Easier just to put the doc in a file, and save that in a group space where
everybody can keep it updated.  If you know where it is, you can always
restore it first thing.  Or email it to yourself.  Or FTP it somewhere.  Or
have all managers keep a paper copy in their car.  Whatever.  I think it's
more important to keep it current, than to keep it in TSM.
 
 
 



From: ADSM: Dist Stor Manager on behalf of Bell, Charles (Chip)
Sent: Wed 5/16/2007 10:47 AM
To: ADSM-L@VM.MARIST.EDU
Subject: 'define machine' for DRM, is it necessary?



If what you see below is what I have set up for DRM, do I have to set up
machines and associations for my TSM server and clients in TSM? Will this
info not be brought back after mksysb and TSM DB restore (using DRM)?



tsm: TSMq drmstatus



Recovery Plan Prefix: /drm/plan/tsm

Plan Instructions Prefix: /drm/instruction/tsm

Replacement Volume Postfix: @

Primary Storage Pools: DATABASE_MANAGE DATABASE_MIGRATE

DATABASE_MIGRATE_LTO2 DATABASE_VTL_3592

EMAGEON2_MIGRATE EMAGEON_MANAGE

EMAGEON_MIGRATE EXCHANGE_MIGRATE

EXCHANGE_VTL_3592 INFORMIX_MANAGE

INTEL_MIGRATE META_DISK META_MIGRATE

SANDIRECT_MIGRATE SPACEMGPOOL UNIX_MANAGE

UNIX_MIGRATE

Copy Storage Pools: DATABASE_OFFSITE DATABASE_OFFSITE_LTO2

EMAGEON2_OFFSITE EMAGEON_COPY

EXCHANGE_OFFSITE INTEL_OFFSITE

META_OFFSITE SANDIRECT_OFFSITE

UNIX_OFFSITE

Not Mountable Location Name: Waiting for Courier

Courier Name: Iron Mountain

Vault Site Name: Iron Mountain

DB Backup Series Expiration Days: 5 Day(s)

Recovery Plan File Expiration Days: 14 Day(s)

Check Label?: No

Process FILE Device Type?: No

Command File Name:



God bless you!!!

Chip Bell
Network Engineer I
IBM Tivoli Certified Deployment Professional

Baptist Health System
Birmingham, AL







-
Confidentiality Notice:
The information contained in this email message is privileged and
confidential information and intended only for the use of the
individual or entity named in the address. If you are not the
intended recipient, you are hereby notified that any dissemination,
distribution, or copying of this information is strictly
prohibited. If you received this information in error, please
notify the sender and delete this information from your computer
and retain no copies of any of this information.


Continuity of Data Backup

2007-05-17 Thread Avy Wong
Hello,
  We have two instances TSM_A and TSM_B, Currently we want to move some
nodes  from TSM_A to TSM_B.  Once the nodes are moved to TSM_B, the
filespaces will be backed up over TSM_B. Is there a way to keep continuity
of the backed up data ? Do I need to move the backed up data of those nodes
from TSM_A to TSM_B? How do I go about it? Thank you.

Avy Wong
Business Continuity Administrator
Mohegan Sun
1 Mohegan Sun Blvd
Uncasville, CT 06382
ext 28164
**
The information contained in this message may be privileged and confidential and
protected from disclosure. If the reader of this message is not the intended 
recipient, or
an employee or agent responsible for delivering this message to the intended 
recipient,
you are hereby notified that any dissemination, distribution, or copy of this
communication is strictly prohibited. If you have received this communication 
in error,
please notify us immediately by replying to the message and deleting it from 
your
computer.
**


Re: 'Q LIC' showing TSM Extended Edition not in use?

2007-05-17 Thread Prather, Wanda
I really don't know.
But as long as your q license says valid, you're fine.



From: ADSM: Dist Stor Manager on behalf of Bell, Charles (Chip)
Sent: Thu 5/17/2007 1:46 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: 'Q LIC' showing TSM Extended Edition not in use?



Thanks for your reply! I have to tell you that I was confused seeing that,
considering Extended Edition is what it is primarily because of having DRM as
a component. And we use it, but 'q lic' showed Extended Edition not in
use(?). SO you are saying that is a misprint?  Again, thanks!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Prather, Wanda
Sent: Thursday, May 17, 2007 11:39 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] 'Q LIC' showing TSM Extended Edition not in use?


why am I seeing the output below, though I am using DRM?

There is no longer a separate license for DRM.  (WHY it displays the way it
does, who knows - the marketing changes for TSM licensing have galloped far
ahead of the server code.)  If you enter HELP REGISTER LICENSE, you'll see
there are only 2 licenses to register for TSM 5.3.

Will this affect a DRM test in August,


NO.





tsm: TSMq lic



Last License Audit: 05/16/07   00:01:07

Is Tivoli Storage Manager for Data Retention in use ?: No

Is Tivoli Storage Manager for Data Retention licensed ?: No

Is Tivoli Storage Manager Basic Edition in use: Yes

Is Tivoli Storage Manager Basic Edition licensed: Yes

Is Tivoli Storage Manager Extended Edition in use: No

Is Tivoli Storage Manager Extended Edition licensed: Yes

Server License Compliance: Valid





God bless you!!!

Chip Bell
Network Engineer I
IBM Tivoli Certified Deployment Professional (ITSM 5.2)
Baptist Health System
Birmingham, AL
Office (205) 715-5106
Pager (205) 817-0357
Home (256) 739-0947
Cell (256) 347-7294





-
Confidentiality Notice:
The information contained in this email message is privileged and
confidential information and intended only for the use of the
individual or entity named in the address. If you are not the
intended recipient, you are hereby notified that any dissemination,
distribution, or copying of this information is strictly
prohibited. If you received this information in error, please
notify the sender and delete this information from your computer
and retain no copies of any of this information.


Exchange 2007 Backups

2007-05-17 Thread Collins, Brenda
Has anyone come up with a solution on how to backup Exchange 2007 on a
64 bit Operating system?  We need to implement a solution by June for
this application and Tivoli is not going to have support until 4th
quarter of this year.

Thank you in advance for any help you can offer!

--
Medtronic
Collins, Brenda
Sr. Principle Systems Admin
[EMAIL PROTECTED]
tel: 763-514-4969
mobile: 763-218-9596
--
Always have my latest info
https://www.plaxo.com/add_me?u=60130810166v0=1860631k0=2093372666src
=client_sig_212_1_card_joininvite=1  Want a signature like this?
http://www.plaxo.com/signature?src=client_sig_212_1_card_sig

___
CONFIDENTIALITY AND PRIVACY NOTICE
Information transmitted by this email is proprietary to Medtronic and is 
intended for use only by the individual or entity to which it is addressed, and 
may contain information that is private, privileged, confidential or exempt 
from disclosure under applicable law. If you are not the intended recipient or 
it appears that this mail has been forwarded to you without proper authority, 
you are notified that any use or dissemination of this information in any 
manner is strictly prohibited. In such cases, please delete this mail from your 
records.

To view this notice in other languages you can either select the following link 
or manually copy and paste the link into the address bar of a web browser: 
http://emaildisclaimer.medtronic.com


Re: Exchange 2007 Backups

2007-05-17 Thread Del Hoobler
Brenda,

Are you talking about standard Exchange Server 2007 legacy backup
and restore or VSS support?

If you look in this list server... last Friday (5/11),
you will see that I posted an announcement that
the Exchange Server 2007 support is available now.
(It's the VSS support that is targeted for 4th quarter.)

Thanks,

Del



ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 05/17/2007
03:30:12 PM:

 Has anyone come up with a solution on how to backup Exchange 2007 on a
 64 bit Operating system?  We need to implement a solution by June for
 this application and Tivoli is not going to have support until 4th
 quarter of this year.

 Thank you in advance for any help you can offer!

 --
 Medtronic
 Collins, Brenda
 Sr. Principle Systems Admin
 [EMAIL PROTECTED]
 tel: 763-514-4969
 mobile: 763-218-9596
 --
 Always have my latest info
 https://www.plaxo.com/add_me?u=60130810166v0=1860631k0=2093372666src
 =client_sig_212_1_card_joininvite=1  Want a signature like this?
 http://www.plaxo.com/signature?src=client_sig_212_1_card_sig



___
 CONFIDENTIALITY AND PRIVACY NOTICE
 Information transmitted by this email is proprietary to Medtronic
 and is intended for use only by the individual or entity to which it
 is addressed, and may contain information that is private,
 privileged, confidential or exempt from disclosure under applicable
 law. If you are not the intended recipient or it appears that this
 mail has been forwarded to you without proper authority, you are
 notified that any use or dissemination of this information in any
 manner is strictly prohibited. In such cases, please delete this
 mail from your records.

 To view this notice in other languages you can either select the
 following link or manually copy and paste the link into the address
 bar of a web browser: http://emaildisclaimer.medtronic.com


LTO2 autoloader

2007-05-17 Thread Joe Crnjanski
Hello,

Does anybody need IBM LTO2 7 tapes autoloader?

Just removed from data centre. Excellent condition.
Purchased Apr/04
Toronto, Canada

Price negotiable.

Regards,

Joe Crnjanski
Infinity Network Solutions Inc.
Phone: 416-235-0931 x226
Fax: 416-235-0265
Web: www.infinitynetwork.com


Re: STORAGE MANAGER FOR MAIL

2007-05-17 Thread Lepre, James
Hey Everyone, 
 
I am having problems with Storage Manager for Mail.  I am getting
the error ACN5705W with a RC = 612.  Any suggestions on how to rectify
the this situation.
 
This error occurs when I try to open the TDP GUI.  
 
Version of Server TSM 5.2.3.5 running on AIX 5.2
 
Verison of STORAGE Manager for Mail 5.4 running on Windows 2003
Enterprise - Exchange 2003 Enterprise
 
Any help always appreciated
 
Thank you 
 
Jim 

  
  
---
Confidentiality Notice: The information in this e-mail and any attachments 
thereto is intended for the named recipient(s) only.  This e-mail, including 
any attachments, may contain information that is privileged and confidential  
and subject to legal restrictions and penalties regarding its unauthorized 
disclosure or other use.  If you are not the intended recipient, you are hereby 
notified that any disclosure, copying, distribution, or the taking of any 
action or inaction in reliance on the contents of this e-mail and any of its 
attachments is STRICTLY PROHIBITED.  If you have received this e-mail in error, 
please immediately notify the sender via return e-mail; delete this e-mail and 
all attachments from your e-mail  system and your computer system and network; 
and destroy any paper copies you may have in your possession. Thank you for 
your cooperation.


Re: Continuity of Data Backup

2007-05-17 Thread Stuart Lamble

On 18/05/2007, at 5:01 AM, Avy Wong wrote:


Hello,
  We have two instances TSM_A and TSM_B, Currently we want to
move some
nodes  from TSM_A to TSM_B.  Once the nodes are moved to TSM_B, the
filespaces will be backed up over TSM_B. Is there a way to keep
continuity
of the backed up data ? Do I need to move the backed up data of
those nodes
from TSM_A to TSM_B? How do I go about it? Thank you.


Easiest way to go about this would be to do an EXPORT NODE between
instances, assuming a high speed link between the two instances. If
the link between the two instances is slow (meaning less than the
streaming read rate of the tape drives, or if the importing server
is unable to write as fast as the tape drives can read), you'd
probably be better off doing the export to a file storage pool,
copying the exported files over to the other server, and importing
them (tedious in the extreme, and needs a large chunk of temporary
disk space, but ... well ...)

Alternatively, if you don't have any important archived data for the
nodes in question, you can just cut them over to the new instance,
take the hit of the one-time full increment, and remove them from the
original instance at some appropriate time, according to the
retention policies of the company. This assumes you have enough tape
storage space to take the short-term hit.

Cheers.


Re: Server migration

2007-05-17 Thread Mark D. Rodriguez
Debbie,

I have been out of the office and away from email for a couple of days.  I
will look into your question and see if I can get you some info.  I may
call you tomorrow to get a little more detailed info.

Regards,
Mark

 I am looking at different options to migrate data from our current server,
 version 5.3.3 to a second TSM server, 5.3.5.  Actually the new server will
 have 2 instances of TSM running and I will need to divide the clients
 between the 2, the old one will be retired.  I have several different
 paths that I can follow and am trying to get a little more detailed
 information so I know we can decide on which method to use.

 If I want to migrate server-to-server does the data go into the disk
 storage pool for the node first and then copy off to tape?
 I am using the same library and tapes for the new server that the current
 server uses, will the new server keep the tapes I already have for the
 node or will it write new ones?

 I know there is a lot more to this, I'm just trying to find out how some
 of the processes work.

 Debbie Haberstroh
 Server Administration
 Northrop Grumman Information Technology
 Commercial, State  Local (CSL)
 972-946-5639




Re: Continuity of Data Backup

2007-05-17 Thread Avy Wong
Stuart ,
Yes. I did thought about exporting the data from TSM_A to TSM_B.
As matter of  fact recently I just did a whole bunch of export nodes to
volumes LTO2. They  were a bunch of obsolete nodes that did not need to
stay on TSM to take up real estate and that exercise was painfully slow. I
have not tried exporting node between two instances. I am hoping that if I
do that it will be faster. Well, I guess I will find out. What you have
told me is very valuable information. Thank you for your help.



Avy Wong
Business Continuity Administrator
Mohegan Sun
1 Mohegan Sun Blvd
Uncasville, CT 06382
ext 28164




Stuart Lamble [EMAIL PROTECTED]
Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU
05/17/2007 06:20 PM
Please respond to
ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU


To
ADSM-L@VM.MARIST.EDU
cc

Subject
Re: [ADSM-L] Continuity of Data Backup






On 18/05/2007, at 5:01 AM, Avy Wong wrote:

 Hello,
   We have two instances TSM_A and TSM_B, Currently we want to
 move some
 nodes  from TSM_A to TSM_B.  Once the nodes are moved to TSM_B, the
 filespaces will be backed up over TSM_B. Is there a way to keep
 continuity
 of the backed up data ? Do I need to move the backed up data of
 those nodes
 from TSM_A to TSM_B? How do I go about it? Thank you.

Easiest way to go about this would be to do an EXPORT NODE between
instances, assuming a high speed link between the two instances. If
the link between the two instances is slow (meaning less than the
streaming read rate of the tape drives, or if the importing server
is unable to write as fast as the tape drives can read), you'd
probably be better off doing the export to a file storage pool,
copying the exported files over to the other server, and importing
them (tedious in the extreme, and needs a large chunk of temporary
disk space, but ... well ...)

Alternatively, if you don't have any important archived data for the
nodes in question, you can just cut them over to the new instance,
take the hit of the one-time full increment, and remove them from the
original instance at some appropriate time, according to the
retention policies of the company. This assumes you have enough tape
storage space to take the short-term hit.

Cheers.



**
The information contained in this message may be privileged and confidential and
protected from disclosure. If the reader of this message is not the intended 
recipient, or
an employee or agent responsible for delivering this message to the intended 
recipient,
you are hereby notified that any dissemination, distribution, or copy of this
communication is strictly prohibited. If you have received this communication 
in error,
please notify us immediately by replying to the message and deleting it from 
your
computer.
**


Re: 10 Gbit ethernet

2007-05-17 Thread Remco Post
Keith Arbogast wrote:
 Is anyone running TSM over 10 Gbit ethernet?  Is there any question
 that it would be supported?

 We have two data centers about 60 miles apart. We are planning to
 send backup files from each data center to a 3584 ATL in the other
 via a 10 Gbit ethernet link. The server hardware would be HP DL585-
 G2's with Myricom 10 Gbit NICs and 2.6 Ghz AMD processors. The
 operating system would be Redhat EL 4.

 If anyone else has experience with TSM and 10 Gbit ethernet we would
 be glad to hear about it.

First of all, TSM doesn't care about the ethernet or any other medium,
it does care about IP, so 10 GE is just as fine as anything that meets
your bandwidth requirements.

Now, you do probably need to do some IP tuning to get things to perform.
TSM transfers huge amounts of data in one stream, making it a prime
candidate for jumbo-frames. Since each frame eats cpu time, bigger
frames are better. You also need an huge TCP window for the long
distance. You could probably, if you have a dedicated link, tune your
TCP stack to drop back less than 50% on a packet loss (say 10-20%). In
this way you could possibly get the best there is to get from your hardware.

Now, you'll probably want to do a lot of tuning at your TSM servers as
well, lots of memory, lots of Db spindles and a quite number of fast
HBAs to connect to your tape and disk-drives.




 Thank you,
 Keith Arbogast
 Indiana University


--
Met vriendelijke groeten,

Remco Post

SARA - Reken- en Netwerkdiensten  http://www.sara.nl
High Performance Computing  Tel. +31 20 592 3000Fax. +31 20 668 3167
PGP Key fingerprint = 6367 DFE9 5CBC 0737 7D16  B3F6 048A 02BF DC93 94EC

I really didn't foresee the Internet. But then, neither did the
computer industry. Not that that tells us very much of course - the
computer industry didn't even foresee that the century was going to
end. -- Douglas Adams


Re: Server migration

2007-05-17 Thread Steven Harris

Debbie

There is no real need to move data you know.

Set up a second copypool so now you have three copies of everything.

Do your final client backups on the old server,  make sure  your
copypools are up to date, mark all tapes unavailable. Backup your database

Restore database to TSMA, delete data for all B nodes. Delete all second
copypool volumes then the copypool itself, resume operations

Restore database to TSMB, delete data for all A nodes.  Delete all first
copypool volumes then the copypool itself, resume operations,  you may
like to reclaim stg at your convenience.

Its a triple somersault without a safety net, but its do-able.

Steve

Haberstroh, Debbie (IT) wrote:

That's what my plan would be.  Hopefully I have enough time to do the moves 
before I need to setup the new server.  I am waiting on disk storage for the 
new diskpools before I can start.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Prather, Wanda
Sent: Thursday, May 17, 2007 11:42 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Server migration


And,
I'd guess that doing MOVE NODEDATA on the source server to make sure you have 
them segregated (preferably into a different pool) would be faster and cleaner 
than server-to-server moves.

Probably.   Just another idea.

W



From: ADSM: Dist Stor Manager on behalf of Allen S. Rout
Sent: Thu 5/17/2007 10:55 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Server migration





On Thu, 17 May 2007 10:56:58 +1000, Steven Harris [EMAIL PROTECTED] said:





There is no escaping it - the server to server move of each node will
require a copy from tape to server1 / across to server 2/ back on to
tape.  The only other option is to just start backing up the nodes to
the new server and at some point delete them from the old.  There are
lots of posts on this topic in the archives.




If you are scrupulously careful about making sure no physical media
holds both some data for target server A and some for target server B,
you can just restore the source DB twice, and

 very.

  very.

   very

carefully delete the unwanted nodes from each target server.


- Allen S. Rout





Re: STORAGE MANAGER FOR MAIL

2007-05-17 Thread Del Hoobler
The manual shows this:
===
ACN5705W
An error was encountered with Tivoli Storage Manager
API initialization, rc = returncode. Examine the dsierror.log
for more information or determine if the TSM API is installed
properly.
Explanation:
An attempt was made to run setup for the Tivoli Storage
Manager API. However, errors were encountered.
System action:
Processing continues.
User response:
Examine the dsierror.log file to determine the problem. If this
file does not exist, it is possible that the TSM API is not
installed properly. If this is the case, reinstall the
TSM API and try running the command again.
===

RC=612

   DSM_RC_NLS_INVALID_CNTL_REC (0612)
   The system is unable to use the message text file.

(The RC612 = DSM_RC_NLS_INVALID_CNTL_REC is in the TSM API manual.)

I would (re)install the TSM BA client so that the TSM API
and its correct parts are (re)installed.
If that does not help, I recommend calling IBM support.

Thanks,

Del




ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 05/17/2007
04:37:34 PM:

 Hey Everyone,

 I am having problems with Storage Manager for Mail.  I am getting
 the error ACN5705W with a RC = 612.  Any suggestions on how to rectify
 the this situation.

 This error occurs when I try to open the TDP GUI.

 Version of Server TSM 5.2.3.5 running on AIX 5.2

 Verison of STORAGE Manager for Mail 5.4 running on Windows 2003
 Enterprise - Exchange 2003 Enterprise

 Any help always appreciated