It works for the email config as well, In case you needed to know Sent from my iPhone
On Jan 24, 2013, at 3:39, Dave Barber <[email protected]> wrote: > ** 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 > 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_ > > _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"
