Regarding the Long Path

I shared my post regarding the Windows long path dilema on the /r/sysadmin subreddit and on G and quite honestly there was quite a reaction. Thank you everyone who took the time to read my article, and I wanted to share something that /u/elkBBQ shared

Source: http://www.xkcd.com/1459/

I had a good chuckle, but on a more serious note. I learned quite a few things from the /r/sysadmin community but I did want to clarify for those who still believe that this is a limitation in the file system (NTFS), but let me tell you it is not. NTFS actually handles up to 32k characters on paths; however, Windows is not able to use it because of a limitation in its API, and while there is some ways to force it like using Unicode and other ways to get around the issue (see link below) there is no office or really a 'good' solution.

I wanted to share the following Article that explains a lot on this issue. The article is written by Kim Hamilton of the BCL Team and as (s)he explains in an answer to a comment:

Diego,

We do need a solution in the underlying windows API, but this would most likely emerge as new APIs rather than changing the existing ones. We've discussed this at length on the longpath alias at Microsoft (yes, we have a whole alias devoted to the issue!) and there are no plans to change the existing ones, since it would break third party code that depend on MAX_PATH buffers on the stack.

We've discussed migration plans to enable those existing Win32 APIs not to enforce MAX_PATH but there are no clear solutions; this would need to be done very carefully to avoid breaking existing Windows-based apps.

The main reason I think we need new Win32 APIs is that \\?\ lumps together long paths and non-canonical paths, so you have to do tricks to get canonicalization on \\?\ paths. That sort of work shouldn't be pushed onto the callers just to achieve long paths.

Thanks,

Kim

Date: 13 Feb 2007 7:08 PM

Sadly in 2007 Microsoft believed this was an issue, and their team were working on a solution. It has been 7 years  and the issue still persists, and from what we know off there is no soon to come fix.

Kind regards to everyone,
Me.

PS. Below I'll post some of the most common work arounds for this issue:

Force Unicode: \\?\PATHHERE (please see the link above for details on how to use this method)
Con: Not widely supported

Map a drive or use subst to map a drive.
Con: Unfortunately the only way to get this to work would be to know the exact path. You'll have to map the drive to a subfolder that is close to the one that breaks the limit. Also doesn't play very well with scripting.

Someone (and I apologize I cannot find the user who posted this on the reddit post)  recommended to use VBScript; however, I do not posses this skill, so if someone could show us a way for this that'd be awesome!

Peter Kriegel pointed me to a PowerShell Module called  File System Security PowerShell Module 3.2.2 but I'm not familiar with it and haven't had a chance to look deep into it as to try to find out who they manage to make it work. Again if someone has some information that they can provide regarding the inner workings, or if indeed truly works I'd appreciate the information. 

Terminal Server has exceeded max number of connections

I received a call requesting assistance one of our users is unable to remote into an SQL server. He is receiving the following error:



I tried to remote as well but received the same error. Then I started researching on how to find the users that are logged in, so that he may communicate with them and ask them to log off, but this brought a very limited amount of information. I found out that the class Win32_LoggedOnUsers doesn't really give you that information, but then I found out that there is a way to bypass the maximum number of connections by using the following command:

%systemroot%\system32\mstsc.exe /admin

Once I logged in I was able to go through the Task Manager and find and log off the extra user, but I was not happy with this solution. I feel like it might not always work. After further looking into this issue I found in Learn-PowerShell that I was able to use the WMI Class Win32_Process to get the Explorer.exe process and get the Owner, thus revealing the logged on users. 

Script found in sauce:

Function Get-WMIComputerSessions {

<#

.SYNOPSIS

    Retrieves tall user sessions from local or remote server/s

.DESCRIPTION

    Retrieves tall user sessions from local or remote server/s

.PARAMETER computer

    Name of computer/s to run session query against.

.NOTES

    Name: Get-WmiComputerSessions

    Author: Boe Prox

    DateCreated: 01Nov2010

.LINK

https://boeprox.wordpress.org

.EXAMPLE

Get-WmiComputerSessions -computer "server1"

Description

-----------

This command will query all current user sessions on 'server1'.

#>

[cmdletbinding(

    DefaultParameterSetName = 'session',

    ConfirmImpact = 'low'

)]

    Param(

        [Parameter(

            Mandatory = $True,

            Position = 0,

            ValueFromPipeline = $True)]

            [string[]]$computer

    )

Begin {

    #Create empty report

    $report = @()

    }

Process {

    #Iterate through collection of computers

    ForEach ($c in $computer) {

        #Get explorer.exe processes

        $proc = gwmi win32_process -computer $c -Filter "Name = 'explorer.exe'"

        #Go through collection of processes

        ForEach ($p in $proc) {

            $temp = "" | Select Computer, Domain, User

            $temp.computer = $c

            $temp.user = ($p.GetOwner()).User

            $temp.domain = ($p.GetOwner()).Domain

            $report += $temp

          }

        }

    }

End {

    $report

    }

}

But I didn't quite need all this so I simply made a one line :




(gwmi win32_process -computer SERVERNAME -Filter "Name = 'explorer.exe'").GetOwner().User 

Now I am able to find out the users that are logged in without having to remote into the server. 

Hope this might help other people out there!