With much urgency, a project I was involved with required an install of Oracle XE and Apex on a server – any server – that we had supplied as part of a small environment built in network-isolated site. We had a Windows 2008 R2 domain controller and two member servers, all sitting on a VMWare ESX host.
I’m not fond of Oracle installations on Windows at the best of times, but Oracle XE is a small database engine, limited to 1 GB of memory usage. The installation went ok, with one minor stupidity, and we were all ready to start configuring the database. Great, open a SqlPlus connection, enter
connect sys as sysdba… and wah-wow, access denied. After a bit more digging, it seemed we couldn’t connect to default database instance. Oracle services were up and running, reboot, same thing.
Hm. Run up
netstat, port 1571 (Oracle default) is listening, blah blah blah.
Ping localhost…. Unable to contact IP driver. General failure. Oh dear, haven’t seen that one before. Maybe something strange in the hosts file? Nope. Can’t ping 127.0.0.1 either.
Since the loopback address is a pretty fundamental part of IP networking, I start wondering if something is wrong with the server builds – I didn’t do them myself, but I had installed all the DC, file and print server roles with no problems. Pinging the server’s own IP is just fine, and network operations between the domain servers seem fine. To check, though, I jump onto the other member server – yup, localhost major fail. I reset the TCP/IP stack on one server using
netsh, and reconfigure the IP4 settings. This does not help. Jump onto the domain controller for another check. Oh-ho,
ping localhost is just fine there.
So, what is the difference between logging on as a domain admin on a DC and logging on with the same account on a domain member server? Basically, for a DC, the domain admin account is the local Adminstrator account as well. With this in mind, I log onto the member servers as local Administrator and the localhost pings work 100%.
SIDs and Sysprep
In the recesses of my mind, something stirs about machine SIDs and weird shit happening on servers when moving between domain and local accounts, particularly in NT days. According to St Mark Russinovich (whose advice I really do rate), there is no requirement to change a machine SID for a modern Windows Server OS. However, if the SIDs are duplicated, it indicates that Sysprep wasn’t run on an imaged OS, which Michael Murgolo emphasised can cause weird problems. These VMs were cloned from a base image.
So I get PSGetSid on one of the machines and run
psgetsid \\* – sure enough, all the servers in the domain have the same SID. Oh dear.
Mark Russinovich has this to say about SIDs on domain controllers:
Every Domain has a unique Domain SID that’s the machine SID of the system that became the Domain’s first DC, and all machine SIDs for the Domain’s DCs match the Domain SID. So in some sense, that’s a case where machine SIDs do get referenced by other computers. That means that Domain member computers cannot have the same machine SID as that of the DCs and therefore Domain. However, like member computers, each DC also has a computer account in the Domain, and that’s the identity they have when they authenticate to remote systems.
The member servers do in fact have the same SID as the DC, but I don’t think we’ve run into a problem in this area. It’s more that the duplicate SIDs are a symptom of the no-Sysprep problem.
It would have been interesting to run a SID-changer over the OS to see what the effect was, but NewSid has been deprecated for years (as mentioned by Russinovich). So, I run Sysprep with the “generalise” option, reconfigure the base OS settings, and rejoin the machine to the domain.
Yippee, localhost ping now works.
How Sysprep makes a difference, I don’t know – the Microsoft KB article only alludes to the fact it makes network changes, but I couldn’t find a reference in Technet to explain what.
With localhost now available, Oracle XE installation and logon to the default instance using the system account work just fine.