When customers won’t conform to your standards…

When working with customer-facing systems, they do not always conform to your standards. A perfect example of this is folder and file names. When users create them, they like to do things like the following:

I like to put spaces in my folder names
I just do it because I think it does not matter to anyone else

With PowerShell, it does not matter as much as it did with string based scripting tools, but I still like a little conformity. My preference it to use CamelCase in my folder naming. While the users customers like their folder names, if I am working with the stuff on the back end, I will typically put it into CamelCase. A perfect example of this is naming groups used for assigning permissions to the folder in question. When my helpdesk person was looking at reconciling permissions on our network drives, the biggest problem was the inconsistency of the naming of the groups to the folder names. My report was saying the folder did not have the correct permissions because I couldn’t find the group that conformed to the folder name. Instead of having my helpdesk person go through and fix all the folder or group names to be the same, I rewrote my report and used this function to help me reconcile the messing customer folder names to my elegant group names. The amount of work that had to be done by my helpdesk person for this project was reduced by over 90%. Let us get to the heart of the matter.

function ConvertTo-CamelCase
{
[CmdletBinding()]
[OutputType([string])]
Param
(
   # String to convert to CamelCase
   [Parameter(Mandatory = $true,
		   Position = 0)]
   [string[]]$TextString
)
Begin {}
Process
{
Write-Verbose "CTCC:StartingValue: $TextString"
foreach ($String in $TextString)
{
Write-Verbose "CTCC:Value of String to process: $String"
If ($String.Contains(" "))
{
	Write-Verbose "CTCC:String has space(s): '$String'"
	$TextInfo = (Get-Culture).TextInfo
	$String = $TextInfo.ToTitleCase($String.ToLower()).Replace(" ", "")
	Write-Verbose "CTCC:OneStepCamelCase String: '$String'"
	Write-Output $String
}
else
{
	Write-Output $String
} #end If String has space
} #end ForEach TextString
} #end Process
End {}
}

You can find the full code on my GitHub account: Function-ConvertTo-CamelCase

The first thing I do is check to see if the provided string has a space in it. If not, I just return the original value untouched. If it does have a space, I then establish a TextInfo object to allow me to modify the provided string. I got this off of someone else’s blog article but that information has been lost through many edits and my changing coding standards (you know, learning my way through it). Since I know the starting string has space(s), I first convert it all to lowercase. Then I use the ToTitleCase method of the TextInfo object. And, finally, I use the Replace method to remove the spaces from the string. I then return the CamelCase’d string as the output of the function.

This is one of my earlier functions and I am sure there are things that can be improved. Additional functionality could be implemented to handle more situations. But, this meets my current needs so I haven’t put any more time into improving my function. I hope you enjoy.

@PSSubmariner

Remove-PSSubShare

I started a GitHub repository to hold my functions.
https:/github.com/PSSubmariner/PSSubFunctions

This function takes a UNC pathed share name as an input. It then will parse the path and determine the server and the name of the share. It will then connect to the server hosting the share with a CIMInstance and removes the share by one of the methods discussed in my previous article. I have tested it against Windows Server 2012R2, Windows Server 2008R3 and Windows Server 2003. On 2008R2, I tested against servers with just PowerShell 2 and no remoting as well as 2008R2 with PowerShell 5 (WMF5). The 2003 server didn’t have PowerShell installed at all.

I have a number of TODO: tags in my script of shortfalls that I can see and want to address over time. But it works in its current state. I have been wanting to blog for a long time but I never felt I was ready or enough of an authority to contribute. I decided recently that I didn’t need to have a perfect function to get started. PowerShell is all about getting in there at the command line and starting to string commands together and when you find something that works, you put it into a script or a function so that you can reuse it. I have been writing basic functions for a long time and started doing Advanced Functions when I started reading the Toolmaking book. I had made a few “advanced” functions prior to this but I didn’t truly understand what I was doing. I was adapting someone else’s Advanced Function to my needs. I am still learning and will continue to do so as any good PowerShell scripter/developer should.

Learn PowerShell Toolmaking in a Month of Lunches

Check out my function and let me know your thoughts.

@PSSubmariner

It is time to stop lurking in the PowerShell community

I have been working with Automation in a Windows environment for a long time. The first tool I worked with was just the DOS batch file. I played with my AutoExec.Bat and did all kinds of amazing and fun things with it. My first language of choice was Perl. I liked the functionality it provided and I could find a plethora of sample scripts that I could adapt to my needs. It was also extremely fast with text/string processing. I dabbled a little with KixStart because my company login script had been written in that language. When I decided to overhaul the login script, I considered Perl but the overhead of installing the Perl engine on all of my corporate desktops was more than I was willing to take on. Looking at the other options available, I opted for learning VBScript as my next language of choice. I had some co-workers who could follow the VBScripts, so I was not alone in my ability to maintain it; an advantage over Perl at the time. I duplicated the functionality of the KixStart script in VBScript and then started extending the functionality with some logs that got integrated into our Intranet on a page used by our support personnel. We had a new co-worker that had some development experience and brought that skill set and expanded the functionality of the login script significantly. He also broke down the VBScript into Subroutines and Functions and building something akin to modules in PowerShell.

But enough of the background on my journey to PowerShell. My interest was peaked by the Monad Manifesto (http://www.jsnover.com/Docs/MonadManifesto.pdf) by Jeffery Snover. I dabbled with it a little in Exchange 2007 but I was not maintaining Exchange as part of my day-to-day job anymore. PowerShell was not yet ready to take over the functionality that VBScript provided me and I was not ready to refactor all of my plethora of scripts that I had accumulated. I continued to follow the development of the language and grew more excited at the prospects. When Microsoft released Windows 7 and Windows Server 2008 R2 with version 2.0 integrated into the OS, PowerShell because a real language that I could start using on a day to day basis. The new cmdlets that were introduced brought a level of functionality that I could really start to use in my day-to-day job. I used books by Don Jones and Jeffery Hicks since I was familiar with them from their VBScript books, as well as Richard Siddaway to start to learn more about the language. They are all quick to point out that the most useful cmdlet in PowerShell is Get-Help. The help that is included in PowerShell by default is amazing in its depth and functionality. When writing my own functions and scripts, I try to emulate that depth and functionality as much as I can. I truly like the examples that are provided. Often when I have an idea to do something in PowerShell, with a little perusal of Get-Help and the Examples section, I find an example that is close to what I want if not an exact match.

Besides the books by those mentioned before and others, I have also learned a lot from the videos by Don Jones, Jason Helmick and Jeffery Snover (The Creator) and others. I would highly recommend the free Microsoft Virtual Academy videos with Jason and Jeffery as they are both very informative and entertaining.

As PowerShell continues to mature and more functionality has been introduced, I have started using it more in my daily activities. I have written many functions and even put together a few modules for my own internal company use. I will be cleaning up and publishing some of these in the Gallery in the not too distant future. That and a GitHub repository (forthcoming) for collaborative development. Coming from the operations side of the house, I have been adopting the developer mentality of using a code repository and organizing my code (much of it modeled around what my co-worker first did with my VBScript-based login script).

I have been following many of the PowerShell personality, on Twitter, YouTube, conferences, PowerShell Saturday, and GitHub. I have been learning from them and absorbing their PowerShell essence. It is time for me to give back and start sharing some of what I have learned along this wonderful journey. I have started writing down ideas for blog posts and I have a few in the works that I will be publishing soon. 

Welcome to my journey. I hope I can give at least a fraction back of what I have learned from this wonderful PowerShell community.

@PSSubmariner