Changing blog again :(

After some time spend at this blog, I decided to move again. I started project OUT-WEB.NET with my colleagues Dennis Damen and Frank-Peter Schultze.

You can follow my posts at http://www.out-web.net – and thanks for support :)

Martin

Microsoft Office 2010 – designed for App-V?

FINALLY Microsoft adopts application virtualization :)

Click-to-Run is a new software delivery mechanism built by the Office product team. It’s based on core virtualization and streaming technologies from the Microsoft App-V team in Cambridge, MA.

http://blogs.technet.com/office2010/archive/2009/11/06/click-to-run-delivering-office-in-the-21st-century.aspx

How to get SCCM site code using Powershell

I spent quite some time scripting SCCM using Powershell – I plan to write some blog post about what I have done, because it is probably most complex scripted solution I ever wrote, but for now, I would like to share one trick with you.

When you script SCCM, you do it through WMI classes. SCCM classes are however not stored in default namespace – therefore whenever you want to access SCCM, you need code that looks similar to below:

Get-WmiObject –ComputerName “ServerX” –NameSpace “Root\SMS\Site_<YouSite> –Class …

Which means that for every script you should accept at least arguments –ComputerName and –SiteCode, which can be pretty annoying to type over and over again. Therefore I use following trick to get sitecode automatically:

# Specify one of SCCM servers and Site code is returned automatically
Function Global:SCCM\Get-Site([string]$ComputerName = $(Throw "Required parameter -ComputerName was not specified in SCCM\Get-Site function")) {
    get-WMIObject -ComputerName $ComputerName -Namespace "root\SMS" -Class "SMS_ProviderLocation" | foreach-object{
        if ($_.ProviderForLocalSite -eq $true){$SiteCode=$_.sitecode}
    }
    if ($SiteCode -eq "") {
        throw ("Sitecode of ConfigMgr Site at " + $ComputerName + " could not be determined.")
    } else {
        Return $SiteCode
    }
}

Problem with path longer than 260 characters

 

Thomas Lee wrote about some issues they are experiencing with Get-ChildItem in this excellent blog post – to make long story short, Powershell is limited by underlying .NET architecture. Thomas mentions mostly performance issues – however I don’t really care about performance as long as it is stable and reliable.

My biggest problem is with path limitation – event though NTFS itself supports paths up to 32.000 characters.

This is error message you get from Explorer when you try to specify longer path:

Very nice blog article about this problem can be found at Coding Horror. Eamon Nerbonne had some nice comments about this problem also.

Why is it so irritating? Almost everyone I mentioned this problem I received answer like “If you run into this problem, it’s your fault, because your are using too long folder\file names”. Shouldn’t 260 characters be enough for everyone?

I don’t think so. First, I don’t see any reason why people shouldn’t use deep structures if they prefer it. I don’t – but that doesn’t mean that everyone had to use same style of work as I do.

That applies to others, but doesn’t describe where is my problem with such limitation. I am mostly focused on enterprise customers – when you implement enterprise solutions, you cannot simply build something, but you must follow some guidelines, like naming conventions. Naming conventions usually apply to all departments – and more people or departments are involved, more complicated they get. If you store your files at network share, their name is also included in that limitation. Let’s consider that our fictional company called “Microsoft” will have development trusted domain. In that case, you can access it using following syntax:

\\CZPRGHOS1DV15.development.microsoft.com\CTX_D_Sources$

On this network share, we store our installation sources. First of course we categorize them, because we got hundreds of applications:

\Office

Ok, so we got installation sources from Office 2007 – because there are multiple editions, we will use iso name as folder name:

\EN_Office_Ultimate_2007_DVD_X12-22244

And that’s it. So our final path is

\\CZPRGHOS1DV15.development.microsoft.com\CTX_D_Sources$\Office\EN_Office_Ultimate_2007_DVD_X12-22244

If we could it together, we are at 101 characters already. Add longest file (\Proofing.en-us\Proof.en\Proof.cab) and we are at 135 characters.

Ok, that’s not that bad, isn’t it? Well, it is. With very basic categorization (no platform, no departments, no versioning etc…), we already reached 50% of the filesystem limit. And don’t forget that Office is VERY flat installation package compared to others (like XenApp for example).

If we have a look at another example, we can use Application Compatibility Toolkit. Longest file name is 174 characters – already after 50%:

"c:\Program Files (x86)\Microsoft Application Compatibility Toolkit 5\Internet Explorer Compatibility Test Tool\Agent Framework\Agents\Bucketizer\BktOutputReverseTransform.xsl"

If we would like to copy it to our sources (\\CZPRGHOS1DV15.development.microsoft.com\CTX_D_Sources$\Admin\Microsoft Application Compatibility Toolkit 5\Internet Explorer Compatibility Test Tool\Agent Framework\Agents\Bucketizer\BktOutputReverseTransform.xsl), we are already at 214 characters (so almost over the limit).