* Rockey Reed <[EMAIL PROTECTED]> [2006-05-01 05:37]: > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Ed Wilts > > Yes. Not just for for NetBackup, but in general, use FQDN whenever > > possible. > > > In this area I cannot help but to disagree with Ed, for whom I have > great respect. The use of FQDN is used too often to mask a poor DNS > configuration. With NBU you need full forward and reverse lookup. When > either is missing a short term solution would be the use of /etc/hosts > files until your network team can fix the DNS by adding the servers IP > address to both zones.
This sounds like an argument FOR using DNS, not against it. :-) Don't forget, the question was about using FQDN, _not_ using DNS. Which way you implement it doesn't really matter (although generally that DOES mean using DNS). Basically, using FQDN is a good idea because it creates genuinely unique client names in NetBackup. Without this, you run a real risk of having two client short names that are the same. You might not see this in a single-company, single-site environment, but it is a real danger in multi-customer or multi-site environments. How many exchange1 servers are out there, I wonder? Imagine in an outsourcing situation where you have to tell client B that the name of their server will have to change because client A got there first (exchange servers don't like having a NBU client name that is different from their real name). The ONLY downside I have come across when using FQDN is when you work heavily in the CLI. It does get tiresome when typing a long FQDN on the commandline to do a bplist or some other activity, but knowing the clients are unique helps a lot. This can also be mitigated quite a bit with scripting and other looping activities off of bpplclients, anyway. -- David Rock [EMAIL PROTECTED] _______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu