I know Terminal Services are dead – however using RDS wouldn’t say too much to many people :)
Today I got presentation about this two products. Below you can find my powerpoint presentation, however it will be mostly live demo:
If this topic is interesting for you, I can post more detailed article about it…
Martin
A must see for anyone writing code for PowerShell:
S4Matic is currently using custom function names (technology\verb-noun), however one of reasons is that in future we want to easily migrate to Posh V2.
So situation is that naming convention applied now is NOT according to standards, but once Posh V2 will get adopted, it will be immediately following new naming convention. That allows us to easily migrate without changing any code at customer sites.
Martin
I wrote 2 blog posts about returning values from functions (here and here) in past, however as I just noticed I haven’t posted any solutions there.
There are in fact at least 3 solutions to this problem.
1.) First was already mentioned – don’t use function as function, however as subroutine and assign value back to variable provided by argument.
2.) Second approach is that you can always consider function to return array and only take last element:
$MyVar = [array]$(Function) | Select –Last 1
That will cast output from function to array (even if it has only single member) and then return last element of that array.
3.) Another solution provided by Oisin is to redirect whole script block to null:
“If you have no clue about/control over whether things may or may not emit and/or are just a bit lazy, dot source a script block redirected to $null. Dot sourcing it ensures it is evaluated in root function scope, and also throws all output away.”
function Test {
. {
1, 2, 3
} > $null
return 4,5,6
}
I like Oisin’s approach most – it is not hard to implement and works really nicely.
One warning though – you shouldn’t take this as general solution and it is not recommended. This approach is mostly useful in case you execute some functions from external source (like invoke from XML file) or you have very complex functions with tons of unexpected returns (especially handling with XML files).
This is follow up to my previous post about naming convention in PowerShell and especially need for namespaces.
Oisin shared some details about modules for PowerShell v2 – and these are changes I was looking for.
When you load function from module in Posh V2, you can access it though module. Consider example where my module is called Citrix and contains single function Get-Server.
If there is only single Get-Server function, I can use it directly, however if there are multiple modules with same function name, I must use syntax <Module>\<Verb>-<Noun>.
Our above example is therefore translated to Citrix\Get-Server.
This is naming convention I could use – all I need to do now is to simply change delimiter from “:” to “\” and that’s it – I am ready for Posh V2 ;)
Problem is that I have scripts that acts as containers for functions – similar way how Posh V2 works. Fixing these modules and their function is simple, however it will get much more complicated once I will try to fix different scripts that are using these functions.
For that, I will use following workaround in Posh V1: each function name will be <Module>\<Verb>-<Noun>. So for example my function declaration will looks like this:
Function Global:Citrix\Get-Server {…}
That way once Posh V2 will be released and I will decide that I want to use modules, I only need to change it to Function Get-Server {…} and I will get same user experience as with V1. Simple and not confusing for end users. Functions will have same names in V1 and V2 – and therefore I am prepared for very easy migration to V2 in future.
Recently I posted about “smart” function names I am using – and we had great discussion about it :) I promised I will write some follow up afterwards and here it comes :)
First of all, I would like to say that I BREAK naming convention of PowerShell and I am fully aware of it, however in my situation positives are outweighs negatives. Because number of people that are not following naming convention is growing, I think there is chance there are some small gaps in PS design that leads to this situation.
First let’s discuss what is naming convention for PowerShell functions:
<Verb>-<Noun>
Good and simple example is New-Object. However what if you need to be more specific? For example what if you want to create new object in SCCM?
Then official way to do so would be New-SCCMObject.
According to official naming convention, retrieving all SCCM related functions can be achieved by calling Dir Function:*-SCCM*.
You can find Microsoft document about PowerShell naming convention here and I highly recommend reading it.
You shouldn’t change verb, only noun.
At least based on my experiences, new comers to PowerShell have problems to understand this – most time I saw first scripts from someone, they almost always started with SCCM-* (or any other technology-based prefix). Maybe it’s caused by fact that flexibility to noun is not stressed enough, I think it is caused by missing element of naming convention – ability to specify script category or technology.
Most time I heard some complains about any changes to naming conventions, arguments were that I am breaking existing naming convention. It is true – however that doesn’t say anything about fact that maybe current naming convention should be tweaked little bit to be more flexible – at least due to fact that popularity of PowerShell is growing and especially with modules from Posh V2 exchangeability of PowerShell will be even improved.
My personal feeling is that once someone will decide that existing naming convention doesn’t fit his requirements (for any reason), field is completely opened for him and he can do whatever he wants. Most of the time result is technology-based prefix, however sometimes we can see absurdities like the ones from Citrix ;)
Another common argument is that administrators will have problems with accepting longer function names – but that’s why we have aliases ;)
Another reason why I don’t like always current naming conventions is automation – there is no delimiter between script category and script itself (noun + any extension is single element). To give you example – I am currently using <NameSpace>:<Verb>-<Noun> syntax. If there will be someone that doesn’t like it and would like to switch to default <Verb>-<Noun> syntax, he can use simple function that will just do <Verb>-<NameSpace><Noun> – for example “translate” function Citrix:Get-Farm to Get-CitrixFarm. This is possible due to fact that there is delimiter between namespace (I know it is NOT a namespace, but I like to use that name ;)) and rest of function name. It won’t work other way around – there is no chance how to detect that “Citrix” in “CitrixFarm” is category. Another example is Dmitry’s post called “We need namespaces!” – IF there would be clear delimiter between namespace and function name, you could easily write “using” function yourself - either using same example as Dmitry provides or even better, using script block:
Use-NameSpace –NameSpace Quest.ActiveRoles.ADManagement –Process {
Get-User “Dmitry Sotnikov” | Set-User –city “St. Petersburg”
}
You don’t need to extend PowerShell itself to support this – just write few simple functions and apply consistent naming convention.
What I am missing is some industry standard – which delimiter should be used? Should it be “:” as I do, should it be “\” as Dmitry suggests or should it be “::” as in Kirk’s example? I don’t really mind – as long as there is something that everyone will follow, I would be more than happy to change my scripts according to this standard.
There are few reasons why I like to use category prefixes:
Even Jeffrey agrees that this is important to solve somehow. What I am missing at this moment is some kind of naming conventions reservation – I don’t mind how long it will take Microsoft to implement it, however I would like to know how it will looks like, so I could already implement same naming scheme (before it will be too late). There was recent blog post about reservation of keywords – and that’s what I would like to get. Many years ago I started calling my cmd scripts using powershell Verb-Noun syntax, just to get people I worked with used to that logic. Now I would like to do the same – start implementing technologies that will come in future already and prepare people for them.
If you get my point, I highly recommend you vote for Connect feature request We need namespaces from Dmitry Sotnikov.
UPDATE: Read follow up here
Here comes another part of my cloud – this one is not very interesting, because there is nothing special in it, however it is tightly related to next one – keeping installation sources automatically updated.
I keep all my installation sources in Live Mesh divided to three parts:
Live Mesh allows me to automatically synchronize applications between multiple computers – major benefit is definitely Tools, because installation is not needed and I can use it immediately. I know I could run into “Out of space” pretty soon (due to Live Mesh limitation to 5GB), however I don’t use that many applications, so for me it is perfect ;)
What is interesting about this is how I keep all sources automatically up to date and synchronized between multiple computers – but for that, you will need to wait for next blog post ;)
As you all know, official syntax of PowerShell is <verb>-<noun>. For example Write-Script.
However this is not always the case – there are many functions that doesn’t follow this naming convention and reason is usually that function name is already taken or author wants to make obvious to which technology is function related.
You get afterwards function names like SCCMImport-Server or SCCM-ImportServer.
I prefer to use “functionality scopes” (my term, sorry, couldn’t come with something better ;)).
Consider example where I want to create new object in Citrix. Logically I would like to call function New-Object, however that was already taken by PowerShell team ;)
Typically I will create function with name Citrix-NewObject or better New-CitrixObject.
What I can do instead is that I can prefix verb-noun:
Citrix:New-Object
It is much easier to use and read, also allows you to use simple dumps (Dir Function:Citrix:* to get all Citrix-related functions).
