Using Windows 7 runas for dsa.msc mmc causes error 740: The requested operation requires elevation.

Microsoft's User Account Control in Windows 7 Professional

This is my first really bad experience with Microsoft's new User Account Control (UAC).  Something caused our long-used and well trusted service account to be disabled.

After installing Windows Server 2003 Administrative Tools Pack so I can use MMC snap-in "Domain Users and Computers" (dsa.msc) on my local PC and after a few runas error 193, I kept getting the following error message:

C:\>runas /user:"domain\username" "mmc %windir%\system32\dsa.msc"
Ento start mmc C:\Windows\system32\dsa.msc as user "domain\username" ...
RUNAS ERROR: Unable to run - mmc C:\Windows\system32\dsa.msc
740: The requested operation requires elevation.

The solution was to call 'cmd /c' which tells 'cmd' to open and run the command supplied as a parameter, which is our mmc command:

C:\>runas /user:"domain\username" "cmd /c mmc %windir%\system32\dsa.msc"
Enter the password for domain\username:
Attempting to start cmd /c mmc C:\Windows\system32\dsa.msc as user "domain\username" ...


...now it works! :)

Oracle database connections lost contact across firewalls/networks

The Problem:

At work during the quietest periods of activity, our database connections would sometimes become unusable and create an exception when used.  It took us a lot of effort to track down the problem to firewalls killing them without ADO.NET knowing.  This tended to happen with Oracle and the exception was one of the following:

• ORA-03135: connection lost contact

• ORA-03113: end-of-file on communication channel

The comms goes like:

Internet-based-client =firewall=> DMZ service =firewall=> DB-on-private-LAN

The Cause

The connections were created in the DMZ and traversed the network boundary through the firewall and to the DBMS in the private LAN.  This firewall was set to automatically kill idle TCP/IP sessions after a max time period (I'm informed this is normal behaviour.  With connection pooling turned on (default), ADO.NET will only know a connection has been severed in this way the next time it tries to use it.

Example: User X uses our website, creating a new connection and once their website session ends, the connection is returned to the pool.  The firewall kills the TCP/IP session used by the database connection because it's timed out through inactivity.  User Y uses the website which tries to reuse the database connection and it fails with an exception.

The Solution

We can limit the max lifetime of a connection to prevent connections sitting idle for too long either:

• Employ a custom solution for retrying, clearing connection pool, etc.
• Using 'Connection Lifetime=XXXX' in the connection string.
• Setting SQLNET.EXPIRE_TIME on the client (if using full, non-xcopy version of the Oracle client), or on the server (sqlnet.ora file in ORACLE_HOME\network\admin).

At first we employed a custom solution that retried opening connections, clearing pools and all sorts of black magic!.  Now we've learnt of connection string setting 'Connection Lifetime':

Connection Lifetime

• MSDN: When a connection is returned to the pool, its creation time is compared with the current time, and the connection is destroyed if that time span (in seconds) exceeds the value specified.  Default is 0.
• To mitigate against severed connections eg across firewalls and networks, ensure to set a timeout value.  We're starting with a value of 3200 (1hr).