Re: O/S Choice for Database Servers

But, I will make a comment on one point. Our AD was very poorly designed and implemented. It is setup like agency.department.net (which if you try to connect via the web, doesn't resolve to anything), while in all actuallity, the address format that does work is in the format of region.agency.gov.

This caused me extreme grief a few years back when installing Oracle, as it auto-magically read the AD information and appended that to my database name, making the database unfindable (and unworkable) in our environment. I finally stumbled upon the fact that if the machine was out of AD and in a workgroup, then no problems with the installation. I have absolutely no idea what would happen if I now changed the machine to be back in AD, now that installation is over.

I've held off on testing this aspect for two main reasons: 1.) It's working fine, so why try something that may break it again? 2.) Due to a big (at least to me), security issue with AD, I will refrain as long as I can from having the server in AD.

<off-topic>
The security issue is that anybody at a higher AD level than myself can easily write a GPO to make themselves an Admin, propagate the new GPO to any machine they want, and have complete control of that machine. When they are done screwing things up, they can just as easily write another GPO to remove themselves from the Admin accounts, leaving everybody scratching their heads as to what happened. We tested this scenario a few years back to confirm, so I decided then that as long as I can, I'll attempt to keep my servers out of AD. If anything happens to them, it's my butt, and the folks we have in our agency that have more permissions than I do, don't know squat about Oracle, they can barely spell SQL Server, but of course being a Micro$oft product, they are totally enamoured with it, even though they don't use that either.
</off-topic>

--

• Bill Ferguson -- http://www.freelists.org/webpage/oracle-l