Session rejected

StiffBoard

ADSM.ORG Senior Member
Joined
Mar 1, 2014
Messages
55
Reaction score
3
Points
0
PREDATAR Control23

Been trying to move backup of an Exchange 2010 to new Spectrum server. Using TDP for Exchange 7.1.4.2, TSM client 7.1.6.4 on two Exchange servers.

Just changing the destination in baclient\dsm.opt, TDPExchange\dsm.opt and TDPExchange\dsmcad.opt.

Created all nodes including DAG node and Proxynode target and agent. Connected to new Spectrum server to generate passwords with TSM client, dsmcutil and tdpexcc.

Checked and doublechecked but I'm missing something here. Trying to do a manual backup I immediately get an error:

Session rejected: Unknown or incorrect user ID...

If I run tdpexcc query exchange I get something similiar, An error occured while obtaining VSS information from the local dsmagent...

This is...probably easy... and stupid. Sorry
 
PREDATAR Control23

An error occured while obtaining VSS information from the local dsmagent
First 5 hits should be able to help you out:
https://www.google.ca/search?q=An+e...ession+rejected:+Unknown+or+incorrect+user+ID

Session rejected: Unknown or incorrect user ID...
Not enough context, it could be the Spectrum Protect nodename, or the Windows user account used for the Exchange backup.

I get something similiar
For future reference, exact error messages starting with ACN or ANS are usually more helpful to use as search criteria
 
PREDATAR Control23

The first hit from that is likely the good one. Looks like it's unavailable at IBM, but Google has a cached copy. The gist of it is:

Finally, run the two commands below to grant each of the admin IDs client owner authority for the nodes whose names they match:

grant authority [TDPforExchangenodename] class=node authority=owner
node=[TDPforExchangenodename]

grant authority [localDSMAgentnodename] class=node authority=owner node=[localDSMAgentnodename]
 
PREDATAR Control23

Not enough context, it could be the Spectrum Protect nodename, or the Windows user account used for the Exchange backup.
Exactly, that's the problem, not enough context...why don't I get to know what ID is wrong?

ANS1353E Session rejected: Unknown or incorrect user ID entered

Yes, I've googled above, can't find anything useful.

I'm back to old files again. Spent the entire day on this...bah.
 
PREDATAR Control23

Looks like something with local access, what is local dsmagent refering to?! Been trying to run the wizards again for client acceptor and so on. Perhaps something wrong with AD account that runs CAD for exchange services, but if I use the old opt files and restart services it works fine. Give up for now...
 
PREDATAR Control23

Looks like something with local access, what is local dsmagent refering to?! Been trying to run the wizards again for client acceptor and so on. Perhaps something wrong with AD account that runs CAD for exchange services, but if I use the old opt files and restart services it works fine. Give up for now...

You don't normally run the CAD with AD accounts - TSM Services should be run with a local account
 
PREDATAR Control23

You don't normally run the CAD with AD accounts - TSM Services should be run with a local account
The AD account has priviligies in Exchange. I'm not the one that set this up initially so I'm not sure if this is neccesary. But my guess it's ok since you are mounting exchange databases and Exchange is spanned over several machines.
 
PREDATAR Control23

DAG backup run under the filesystem node name hence why you have to grant proxy authority to the filesystem client to execute the backup for the DAG node name. In most cases I have seen these errors its because the DAG client is misconfigured. Does everything match as how it was set on the old TSM server? Node Names/Proxies/Passwords...I had to do this with a DAG client from one DC to another. So my DAG setup is as such:

tsm: > Q PROXY
TEST-AP-DAG RND1W023S
RND1W024S
RND1W023S.EXCH
RND1W024S.EXCH


So the EXCH nodes actually don't execute the backup. Through our setup we realized that the Exchange TDP uses the file system nodes to execute the backup through the VSS writer. We use the EXCH node to run the backup script under its own scheduler seperate from the file system client. We had to make sure we had the correct settings in the Exchange tdp config file also.
 
PREDATAR Control23

DAG backup run under the filesystem node name hence why you have to grant proxy authority to the filesystem client to execute the backup for the DAG node name. In most cases I have seen these errors its because the DAG client is misconfigured. Does everything match as how it was set on the old TSM server? Node Names/Proxies/Passwords...I had to do this with a DAG client from one DC to another. So my DAG setup is as such:

tsm: > Q PROXY
TEST-AP-DAG RND1W023S
RND1W024S
RND1W023S.EXCH
RND1W024S.EXCH


So the EXCH nodes actually don't execute the backup. Through our setup we realized that the Exchange TDP uses the file system nodes to execute the backup through the VSS writer. We use the EXCH node to run the backup script under its own scheduler seperate from the file system client. We had to make sure we had the correct settings in the Exchange tdp config file also.

Hi, I like to use TSM Scheduler to get a report in TSM. Checked the proxy settings several times, settings are identical.

tsm:> Q Proxy
Target node Agent node
SERVER01_TDP SERVER01 CAS01_TDP
SERVER02_TDP SERVER02 CAS01_TDP
CAS01_TDP SERVER01 SERVER02 SERVER01_TDP SERVER02_TDP
 
PREDATAR Control23

If it's a Spectrum Protect node issue, at the same time you see ANS1353E on the client side, there will be a message in the activity log to tell you which nodename has an issue. If there is no error messages in the activity log related to ANS1353E at that time, then it's likely an issue with the Windows account.

I would double-check the config from start to finish: https://www.ibm.com/support/knowled...ibm.itsm.mail.exc.doc/t_dpexc_cfg_manual.html Click each link on that page to make sure you didn't skip a step or misconfigured one by mistake.
upload_2017-5-10_8-41-19.png
 
Top