Closing Chrome does not delete session cookies

Traditionally, closing browsers automatically deletes "session" cookies. (Cookies that are defined to represent a login session that should be automatically disconnected when a browser closes.)

In 2012, Chrome changed its behavior so that closing the browser does not delete session cookies. (This newer behavior is active if you enable the common Chrome setting: On startup: Continue where you left off.) This new behavior allows reopening the browser (perhaps hours later, by another person) and having your last active pages, along with any associated login sessions, automatically reloaded. (To be fair, many sites will timeout your session if it seems inactive after a short period of time. But many, e.g., GMail, won't.)

This is a bad thing if you use Chrome on a public access computer (e.g., library). You should now explicitly logout of all sites before closing Chrome. Which means you should be careful not to accidentally navigate away from a logged in site and subsequently forget to navigate back and explicitly logoff.

The pros & cons of this new behavior are discussed in the Chrome bug tracker Issue 128513. It seems primarily useful when Chrome restarts to apply software updates (without forcing you to logoff all your websites). Firefox has similar behavior which is also debated. As pointed out there, this browser behavior is at odds with the documented behavior of session cookies.

There is a Chrome setting to force delete all cookies when the browser is closed. (The "Keep local data only until you quit your browser" option described here.) Unfortunately, this is overkill in most situations.

Bottom line: Be aware.

SQL Server Reporting Services (SSRS) – “HTTP 401.1 – Unauthorized Logon Failed”

Symptom:

When you browse to the ReportServer and Reports virtual roots using the host name specified in your SSL certificate you are prompted three times to log in then land on a blank page.  Or you receive an ‘HTTP 401.1 – Unauthorized: Logon failed’ message. 

Note You only receive this error message if you try to browse directly on the server. If you browse from another computer in the network, the SSRS site works as expected.

Cause:

This issue occurs because of a loopback-check security feature added in Windows Server 2003 SP1. Authentication now fails if the host fully-qualified domain name (FQDN) specified in either your SSL certificate or any custom host header (CNAME) alias that you use, does not match the local computer name.

Work Around:

This issue and workaround is more fully explained in Microsoft articles:

http://support.microsoft.com/kb/926642 

http://support.microsoft.com/kb/896861

You should refer to and follow the instructions there.

If those articles are no longer available, a (possibly now out-of-date) snapshot of the instructions is reproduced below.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

Warning This workaround may make your computer or your network more vulnerable to attack by malicious users or by malicious software such as viruses. We do not recommend this workaround but are providing this information so that you can implement this workaround at your own discretion. Use this workaround at your own risk.

Create the Local Security Authority host names that can be referenced in an NTLM authentication request

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
3. Right-click MSV1_0, point to New, and then click Multi-String Value.
4. In the Name column, type BackConnectionHostNames, and then press ENTER.
5. Right-click BackConnectionHostNames, and then click Modify.
6. In the Value data box, type the CNAME or the DNS alias that is used for the local shares on the computer, and then click OK.
   
   Note Type each FQDN host name on a separate line.
   
   Note If the BackConnectionHostNames registry entry exists as a REG_DWORD type, you have to first delete the BackConnectionHostNames registry entry.
7. Exit Registry Editor, and then restart the computer.

Why ReSharper keyboard shortcuts fail over Remote Desktop Connection

I use the ReSharper plugin for Visual Studio.

I discovered that the reason some of the newer ReSharper keyboard shortcuts only work “sometimes” for me is that they are usurped by Microsoft Remote Desktop Connection (RDC).

E.g., ReSharper’s old Ctl-W is now Ctl-Alt-Left Arrow / Right Arrow.  However those keys are used by RDC (and can’t be changed).

List of RDC Keyboard Shortcuts:
http://windows.microsoft.com/en-us/windows-vista/what-shortcut-keys-can-i-use-in-remote-desktop-connection

A hack workaround:
http://superuser.com/questions/327866/remote-desktop-sending-ctrl-alt-left-arrow-ctrl-alt-right-arrow-to-the-remote-p 

How to make elevated Windows programs recognize network drives

In Windows Vista or newer, if User Access Control (UAC) is enabled, network drives mapped while in a non-elevated state are not accessible to the same user in an elevated (administrator) state.

More detail in Microsoft articles here and here.

For example, after mapping a network drive, P:, from Windows Explorer (not elevated), I launch an elevated command prompt ("Run as administrator") and run the net use command. It shows the drive mapping exists, but rather than Status being OK, it is Unavailable.

Workarounds:

• Map the drive twice: non-elevated and elevated. (E.g., launch an elevated command window and use the net use command.)
• Set a registry setting that will force Windows to make the network drives available to both the standard and administrator accounts automatically:
  

  Create a new DWORD entry with the name HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System/EnableLinkedConnections and value 1.

  See articles here and here.
  Warning: This can cause problems; see this Microsoft hotfix.

• Disable UAC.

How to tell which SQL Server version, service pack, edition, etc. is running

Execute the following query:

SELECT  
    SERVERPROPERTY('productversion') as 'Product Version', 
    SERVERPROPERTY('productlevel') as 'Patch Level',  
    SERVERPROPERTY('edition') as 'Product Edition',
    SERVERPROPERTY('buildclrversion') as 'CLR Version',
    SERVERPROPERTY('collation') as 'Default Collation',
    SERVERPROPERTY('instancename') as 'Instance',
    SERVERPROPERTY('lcid') as 'LCID',
    SERVERPROPERTY('servername') as 'Server Name'

 
This useful info came from this blog post.

Perform an action on (e.g., "drop") all tables in a SQL Server database

Supposed you want to perform an action on all tables in a SQL Server database.  (E.g., delete or truncate every table.)

You could generate a list of all the tables in the database by (first connecting to the database you want then) executing:

SELECT * FROM sys.Tables Order by name ASC

 Or you could use the hidden Microsoft stored procedure, sp_MSforeachtable.

EXEC sp_MSforeachtable @command1 = "PRINT '?'"
      --print the tables names with owner(dbo)

EXEC sp_MSforeachtable @command1 = "SELECT * FROM ?" 
      -- Selects all the rows form all the table

Or more destructively:

EXEC sp_MSforeachtable @command1 = "DROP TABLE ?"

EXEC sp_MSforeachtable @command1 = "DELETE FROM ?"

EXEC sp_MSforeachtable @command1 = "TRUNCATE TABLE ?"

This was gleaned from this blog post.

File Types tab missing -- NirSoft to the rescue

Windows 7 and (worse) Windows Server 2008 no longer provide a GUI to fully edit file type associations.

Earlier Windows versions (e.g., XP) allowed you to edit this via the Windows file system explorer menu Tools > Folder Options... dialog, the File Types tab.   There you could define which program is associated with each file extension:

 

If you pushed "Advanced", you could then view the various file operations that could be performed:

 

And you could redefine how the programs were actually invoked to perform each action:

The "File Types" tab is missing in Windows 7 and Windows Server 2008.

To the rescue is NirSoft with their FileTypesMan utility.