Doug/Ken, Many thanks - I'm sceptical of it being a password as such, as these are test servers on which I've set a generic (arsystem) DSO password. I'll follow through with the password copy on the ar.conf file, we too are on Solaris.
Regards Dave On 24 January 2013 01:24, Ken Pritchard <[email protected]> wrote: > ** ** > One thing I found with earlier versions (might be corrected in V7.6.04) as > recent as 7.6.03 was that the system sometimes didn't store (encrypt) the > DSO password for the target machine correctly. A trick I found is to go > into the ar.conf file (I'm on Solaris) and cut the DSO password for server > A from the conf file on server A and paste it into the line of the server B > conf file for the target DSO password for server A. Didn't even have to > restart the DSO process - picked it right up and started transferring. > Just passing that along as an option to try - only takes a minute to check. > > ----- Original Message ----- > *From:* Mueller, Doug <[email protected]> > *Newsgroups:* public.remedy.arsystem.general > *To:* [email protected] > *Sent:* Wednesday, January 23, 2013 4:22 PM > *Subject:* Re: DSO - issues on 7.6.04? > > ** > > Dave,**** > > ** ** > > Well the message says "Access problem" when trying to get the remote > definition….**** > > ** ** > > So, the question that immediately comes to mind is whether you have > configured the appropriate passwords**** > > for the DSO user to be able to access the remote system? **** > > ** ** > > You can get from B to A but not from A to B. You can get from A to A and > from B to B.**** > > ** ** > > Well, B has a DSO password and you have to configure A to have that > password so that it can talk with B.**** > > ** ** > > I would check the configuration (configured on the Server Information > form) on system A – the one you**** > > cannot call from – to make sure that system B is registered with a > password. If there is a password, it will**** > > not show you the value so you might try entering the right value and > saving just to be sure that you have the**** > > right value configured.**** > > ** ** > > Then, see where that leaves you.**** > > > But, an error of an "access problem" is related to password problems or > port configuration problems or**** > > something that prevents the DSO process on system A from accessing system > B for interaction.**** > > ** ** > > Hopefully this gives a hint that helps in finding a solution,**** > > ** ** > > Doug Mueller**** > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Dave Barber > *Sent:* Monday, January 21, 2013 7:10 AM > *To:* [email protected] > *Subject:* DSO - issues on 7.6.04?**** > > ** ** > > ** All, > > We're not using DSO much - currently only for one transaction type, which > is basically a password sync option between our (in house) incident system > running on 7.0.01 and an ootb change management application running on 7.5 > (incident and its server has always been the primary application) > > In the process of upgrading the 7.0.01 server to 7.6.04 patch 004, and I'm > trying to replicate the DSO functionality between our test environments. > Its licensed on all of them, but when trying to send a DSO transaction from > 7.6.04 to either a 7.0.01 or 7.5 server I'm always getting : > > ** WARNING ** Access problem trying to get target form definition, > later... (Mon Jan 21 2013 14:40:40.9342) > > I've been able to issue DSO transactions the other way round, from 7.5 or > 7.0.01 to 7.6.04, but totally unable to send the other way. Is there an > issue using DSO transactions from a newer version to an older version? > > All servers are running on Solaris/Oracle, DSO is licensed on all servers, > and all servers can issue DSO transactions to themselves (ie. the most > basic DSO transaction works without issue). > > Regards > > Dave Barber > _ARSlist: "Where the Answers Are" and have been for 20 years_ **** > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
