Pritch, Roger, Peter, Just to let you know that I am about to try exactly the same thing at a client site: DSO 7.0 to 7.5 servers so older data is available for reporting. Thanks for sharing your experience with the list!
Doug On Sep 3, 2010, at 1:46 PM, pritch wrote: > When I had the pwd issues, I was going from Sun to Sun servers. If you're > working (partially) in one direction, that segment of the passwords are > probably good. > > In general, the passwords in the conf file need to match up ServerA > DSO-User-Password needs to match ServerB DSO-Target-Password. I had to do > some manual cut and paste between the two to get them to line up. BMC (via > a ticket I had opened) did acknowledge there is an issue with the DSO > target passwords being encrypted in the Dev Studio (and apparently at least > some versions of the admin tool). The workaround I found was to do the cut > and paste. If you know you are communicating between servers (check each > direction separately) then you're OK with the passwords. Could be you're > on a patch on one of the servers that sets up the pwds OK. > > Also make sure the 'To server' designation in your mapping record is the > same as what is in your conf file (i.e. if you have an IP address listed in > the conf file, the to server mapping needs to use the ip address, if you > have a servername set up, the mapping needs to use the servername). > > My guess is that the 'form not found' errors might actually be the fact > that it isn't finding the server, or the password isn't matching up. > > For the direction where some of the fields are going over, you might want > to check the custom mappings to make sure the fields are in the right order > (especially if the field numbers are different). The mapping of the fields > is all numeric - what I can tell from the mapping field the first parameter > should be the field ID of the target server/form and the next to last is > the field ID from the source. > > As an example if you want to move the Status field (field 7) on the form > from Server A to field 1000000001 on the form on server B the line would > look something like \1000000001\102\1\*\1\*\1\7\0\. > > We use DSO to move info between systems sometimes even into different > forms, so it can all be mapped - when it's not like ID's it just gets a bit > more difficult to match up; once the connections and mappings are set right > it works like a charm. > > > On Fri, 3 Sep 2010 14:54:30 -0400, Peter Westergaard > <[email protected]> > wrote: >> Thanks (pri...@ptd), I really appreciate your post. >> >> I thought I had replied, but I don't see it in the list archives so maybe > >> something odd happened to it. Let me re-post my reply here and I hope > I'm >> not repeating myself. >> >> ~~~~ >> >> >> The encrypted passwords don't seem to match (even though I have partial >> tickets being sent reliably from Server A -> B). Let me paste them here >> just to be sure I'm looking correctly. >> >> Server A: ARS 7.1, SunOS 9 >> taken from: /usr/ar/rsd001/conf >> DSO-Target-Password: >> > (ServerB):dkUkuJ2ynqjhy8kjDTuwZEPRvJFohvnOgrDlcSk+A+iX0WnN3jpL2dBe+9tK/zExTa >> MfR0UXU4gnXNcShcsIs/+oQx6I1PT8MXSXpmhSRTTPNvf7riT3Og== >> DSO-User-Password: >> > p2uuldJNOZ7c16QNrMGQ+1UrIND+O4XpZomkGKqRzG2zOzW6JJ9dLjrB/M/ndb1XAML8oM2xEbJO >> lzyFLvUKgcWgnJJ4Avw9nPjMdqHkqeFOKq1qNkRLRA== >> >> Server B: ARS 7.5, Windows Server 2003 Enterprise SP2 >> taken from: E:\Program Files\BMC Software\ARSystem\Conf >> DSO-User-Password: >> > 4xJShm2ju7SkAtFLn+c9q8m2HXzjUDsJ6CGxaMu6JVMrmOX4uQlexrv/1ichCPKrltoOaEOX8b/L >> QXzE6anlZ0e8b074UFHPd+YrgDybozdsYh6dID78+w== >> DSO-Target-Password: >> > (ServerA):W90MOeK9xbwozXQbnIdz+WNqxVLAzBmSnKmh1UOyre13sRPcYN4fJaZHTfjy5kEAro >> R9FlDo3EV53iI5gbmfyLkWYeublc/xvlOA5O4WD74Ct+jraGDlNg== >> >> I do notice that the DSO-Target-Password depends on exactly how the > server >> name is registered. If I use the IP instead of the server name, I get a >> different encryption. (Neither one matches the DSO-User-Password on the >> remote server though). So you're suggesting that the DSO-Target-Password >> on >> Server A should match the DSO-User-Password on Server B? >> >> For the rest of the questions... I'm using custom mappings, the fields > all >> exist, are Optional (not Display Only), and have Public change permission >> on >> them, on both servers. (They specifically have different field IDs > because >> we're doing a Proof-of-Concept of using DSO between non-congruent forms - >> so >> far, the concept isn't looking proven). I do intend to create an exact >> copy of the source form onto the target server and see if Like IDs helps. >> >> I've tried setting the Duplicate Records setting to 'Overwrite' and > 'Create >> New' but changing the setting doesn't affect the outcome (in either >> direction). >> >> I'll post more details when I perform a few more configuration tests. >> Also, >> I'll see what I can do about getting the encrypted passwords to match. >> >> > _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" Doug -- Doug Blair [email protected] +1 224-558-5462 200 North Arlington Heights Road Arlington Heights, Illinois 60004 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
<<inline: bmc_skilled_pro_ar.png>>
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
