Reading through various posts, articles and guides I've come across references to IDE's and ISE's, and had no idea what on earth they were. I think it's typical case of programming types assuming everyone knows these things, while forgetting that those of us from a non-programming sysadmin point of view (after all the main forcus of PowerShell) won't have heard of them before.
It took me a while to get my head around what they actually refer to, so I thought I'd share what I found. In simple terms :
ISE = Integrated Script Environment
IDE = Integraded Development Environment
so essentially they're both fancy names for a script editor with some fancy bells and whistles!
There certainly seem to be a wide variety of editors out there to choose from, both free and commercial, with many apparently including support for other languages as well, which might be useful for some people. I've been a long term fan of EditPlus as my editor of choice for scripting, especially after discovering that you can download additional syntax lists for it, so it can do all the colour coding of your code even with new languages. For PowerShell though, especially seeing some of the alternatives out there, I think it might be time to move on!
The editor I've ended giving a try is PowerGUI, since it's free and seems to have some very handy features which will certainly help with learning the language. I'll admit I was a little hessitant about the whole Intellisense thing, since it's not something I've really used before, but the help in remembering which switches etc are available will certainly help. The other thing I particularly like is the mouse over help, which gives you a quick reminder of the complete syntax of the relevant command.
Of course now I just have to get my head around the language itself! It's weird to think this is the first time since I was a student where I've tried to learn a new language properly! :-) OK, so it's the slower method, but I think it'll be worth the effort to learn it properly, and therefore use it properly, rather than just try finding the new commends to do old methods, and not get the full benefit of the language. I've already seen so many posts from people talking about using old methods rather than making full use of the pipeline, so I'm determined to do it properly.
Wednesday 21 July 2010
Thursday 8 July 2010
Master PowerShell ebook
Just a quick one today. If you're looking for a good indepth guide to powershell, then this is probably just what you're after :
http://powershell.com/cs/blogs/ebook/
Written by Dr. Tobias Weltner, it's available either online as html pages so you can skip to the sections you need, or there's a free ebook download available of the entire book.
http://powershell.com/cs/blogs/ebook/
Written by Dr. Tobias Weltner, it's available either online as html pages so you can skip to the sections you need, or there's a free ebook download available of the entire book.
Tuesday 6 July 2010
The confusion over SQL Server backups
Something occured to me the other day... the collective wisdom of the internet isn't always a good thing, especially when dealing with something that has many people confused!
I had a moment of self doubt recently, brought on by the need to explain SQL backups to someone. I wanted to make sure that what I thought was correct really was, rather than simply soldier on and risk passing on a poor understanding to an unknowing recipient. What I found though were a lot of people who think they understand SQL backups, but who clearly don't!
So what is it they don't get you ask?
Well generally speaking the connection between different type of backup, and their effect on the transaction log. I saw people thinking that a full backup would cause old transaction log records to be cleared, and other people thinking that differential backups use the transaction log for its data... both of which are wrong. So to be clear...
Full Backups - Only the database (.mdf) itself is backed up*, the transaction log isn't touched, and it will continue to grow as always.
Differential Backups - Only the database (.mdf) itself is backed up, by backing up those extents within the database which are marked as having changed since the last Full backup. The transaction log isn't touched.
Transaction Log Backups - Finally the transaction log file is used, and the completed transactions marked as such so the space can be re-used / cleared, or more accurately, the inactive portion of the log is truncated.
So the critical thing here is that if you have a database in Full or Bulk-logged recovery mode, you must have a transaction log backup done at some point, even if you don't plan to use it. Otherwise the transaction log will never be truncated, and it will just continue to grow until it runs out of space. Or of course, consider simply changing the recover mode to simple.
For a couple of good guides explaining it check out
http://www.teratrax.com/articles/sql_server_backup_types.html
and
http://www.sqlservercentral.com/articles/64582/
* yes I know that the transactions made during the process of the backup are then backed up from the transaction log at the end, but lets not confuse matters here.
I had a moment of self doubt recently, brought on by the need to explain SQL backups to someone. I wanted to make sure that what I thought was correct really was, rather than simply soldier on and risk passing on a poor understanding to an unknowing recipient. What I found though were a lot of people who think they understand SQL backups, but who clearly don't!
So what is it they don't get you ask?
Well generally speaking the connection between different type of backup, and their effect on the transaction log. I saw people thinking that a full backup would cause old transaction log records to be cleared, and other people thinking that differential backups use the transaction log for its data... both of which are wrong. So to be clear...
Full Backups - Only the database (.mdf) itself is backed up*, the transaction log isn't touched, and it will continue to grow as always.
Differential Backups - Only the database (.mdf) itself is backed up, by backing up those extents within the database which are marked as having changed since the last Full backup. The transaction log isn't touched.
Transaction Log Backups - Finally the transaction log file is used, and the completed transactions marked as such so the space can be re-used / cleared, or more accurately, the inactive portion of the log is truncated.
So the critical thing here is that if you have a database in Full or Bulk-logged recovery mode, you must have a transaction log backup done at some point, even if you don't plan to use it. Otherwise the transaction log will never be truncated, and it will just continue to grow until it runs out of space. Or of course, consider simply changing the recover mode to simple.
For a couple of good guides explaining it check out
http://www.teratrax.com/articles/sql_server_backup_types.html
and
http://www.sqlservercentral.com/articles/64582/
* yes I know that the transactions made during the process of the backup are then backed up from the transaction log at the end, but lets not confuse matters here.
Monday 5 July 2010
PowerShell help system and reference site
So I've been reading various bits of information about PowerShell recently, and I think perhaps the most important thing I've seen is the quality of the help system. After all, who wants to try memorising masses of cmdlet switches and options, when you might only use them once in a blue moon!
Checking out the wealth of information flowing forth from the get-help cmdlet was very satisfying, made me reminisce of my days with the Linux Man pages, in fact it's nice to see that not only has 'man' been setup as an alias for get-help, but it's even been aliased to use ' more', making it function more like the traditional man system.
I have got one complaint though which I've yet to find a resolve for (if there is one), and that's the inability to scroll back up the page. Great I can page down with Space, go down a line with Enter, but how do I go back up!?! It would have been nice to be able to use the up and down arrows as well like you can with man, so you can view the detail of an option, and then scroll back up to the syntax list or where ever without having to leave help and start again.
Hopefully I'm just missing something somewhere, but so far I don't think so.
By the way, if you're looking for a good guide to PowerShell then I can highly recommend the Windows PowerShell v2.0 Reference from the Microsoft scripting guys which you can find here http://blogs.technet.com/b/csps/p/psref.aspx. It covers all the basics you'll need to know, and points you in the right direction to find out more. Plus I've always liked the informal writing style of the scripting guys, it's a much nicer read than your average MS reference.
Checking out the wealth of information flowing forth from the get-help cmdlet was very satisfying, made me reminisce of my days with the Linux Man pages, in fact it's nice to see that not only has 'man' been setup as an alias for get-help, but it's even been aliased to use ' more', making it function more like the traditional man system.
I have got one complaint though which I've yet to find a resolve for (if there is one), and that's the inability to scroll back up the page. Great I can page down with Space, go down a line with Enter, but how do I go back up!?! It would have been nice to be able to use the up and down arrows as well like you can with man, so you can view the detail of an option, and then scroll back up to the syntax list or where ever without having to leave help and start again.
Hopefully I'm just missing something somewhere, but so far I don't think so.
By the way, if you're looking for a good guide to PowerShell then I can highly recommend the Windows PowerShell v2.0 Reference from the Microsoft scripting guys which you can find here http://blogs.technet.com/b/csps/p/psref.aspx. It covers all the basics you'll need to know, and points you in the right direction to find out more. Plus I've always liked the informal writing style of the scripting guys, it's a much nicer read than your average MS reference.
Sunday 4 July 2010
Getting started with PowerShell
So what is it about PowerShell that interests me? Well as someone who started out in the server admin world with a hand full of Linux boxes, albeit in a fairly amateur capacity, I've always naturally been comfortable working at a command prompt. In a Windows world though it's always seemed that to automate anything via scripting there are so many ways to do things, depending on what you want to achieve, with none of them really covering all the bases. Traditional batchscripts, vbscript, wmi, adsi, no one scripting technology really covers everything, and you end up using a collection of things, with one method calling another method etc, since each method lends itself so well to some things more than others.
For instance, I in one script I wrote, you've got a batchscript handling the basic flow and logic of the script, that then calls a few of the GNU ported linux functions like grep, tail, wget etc, and uses vbscript to handle sending e-mail using the JMail component, and at one point calling WMI functions as well!
When I first heard about PowerShell it sounded like finally there might be a language I could invest some time into learning, safe in the knowledge that it could cover what ever I was trying to achieve. Of course like many things there was the question, 'is this too good to be true?', and at first it was. After all, it's great that you can control Windows 2008, Exchange 2007 and SQL Server 2008 etc via PowerShell, but when you're still predominantly using 2003, 2003 and 2005, that's not a lot of use. Now of course things have changed, and it's worth taking the time to learn the language, so that's what I'm determined to do. I think my first challenge will be to get my head about the basics of the language itself, and how the flow control etc is supposed to work, and then work on re-writing many of my more commonly used scripts to use PowerShell instead.
I'll keep you posted on how I get on.
For instance, I in one script I wrote, you've got a batchscript handling the basic flow and logic of the script, that then calls a few of the GNU ported linux functions like grep, tail, wget etc, and uses vbscript to handle sending e-mail using the JMail component, and at one point calling WMI functions as well!
When I first heard about PowerShell it sounded like finally there might be a language I could invest some time into learning, safe in the knowledge that it could cover what ever I was trying to achieve. Of course like many things there was the question, 'is this too good to be true?', and at first it was. After all, it's great that you can control Windows 2008, Exchange 2007 and SQL Server 2008 etc via PowerShell, but when you're still predominantly using 2003, 2003 and 2005, that's not a lot of use. Now of course things have changed, and it's worth taking the time to learn the language, so that's what I'm determined to do. I think my first challenge will be to get my head about the basics of the language itself, and how the flow control etc is supposed to work, and then work on re-writing many of my more commonly used scripts to use PowerShell instead.
I'll keep you posted on how I get on.
Saturday 3 July 2010
Just starting out
It's a funny thing, but throughout years of being a computer geek, and over ten years now working as a Sys Admin, I've never really had a go at blogging before now.
I suppose there are a couple of reasons behind this. Firstly, while I love technology of course, I've never been a massive fan of technology for its own sake. Sure, show me a shiny new toy and I'll drool like the next geek, but once the spittle has dried, the reality dawns that while pretty or simply cool in a geek way, the lustre far outweighs the substance. Secondly, and perhaps more specific to blogging, I've never seen the point of blogging for the sake of blogging. Don't get me wrong, there are a lot of fantastic blogs out there that I've enjoyed reading over the years, but unless you have something worthwhile to say, you're doomed to end up as yet another "for breakfast I had...", "same stuff different day...", "isn't 'stuff' great..." blogger.
So considering what I've said above, what made me decide to start this blog now? Well over the years there have been the odd things here and there that I've thought it might be interesting to write about, but never sufficient to bother starting a blog just for them. Recently though I've been reading more and more about PowerShell, and finally decided to take the plunge and learn it. I've read loads of articles, guides and blogs relating to using PowerShell, many of which are fantastically written, but one thing I've noticed is that they all seem to be from people who are already quite competent programmers. I've done my fair share of scripting over the years to automate various sysadmin tasks, but I'm far from proficient, so I thought it might be interesting to write about my experiences from that angle.
I suppose there are a couple of reasons behind this. Firstly, while I love technology of course, I've never been a massive fan of technology for its own sake. Sure, show me a shiny new toy and I'll drool like the next geek, but once the spittle has dried, the reality dawns that while pretty or simply cool in a geek way, the lustre far outweighs the substance. Secondly, and perhaps more specific to blogging, I've never seen the point of blogging for the sake of blogging. Don't get me wrong, there are a lot of fantastic blogs out there that I've enjoyed reading over the years, but unless you have something worthwhile to say, you're doomed to end up as yet another "for breakfast I had...", "same stuff different day...", "isn't 'stuff' great..." blogger.
So considering what I've said above, what made me decide to start this blog now? Well over the years there have been the odd things here and there that I've thought it might be interesting to write about, but never sufficient to bother starting a blog just for them. Recently though I've been reading more and more about PowerShell, and finally decided to take the plunge and learn it. I've read loads of articles, guides and blogs relating to using PowerShell, many of which are fantastically written, but one thing I've noticed is that they all seem to be from people who are already quite competent programmers. I've done my fair share of scripting over the years to automate various sysadmin tasks, but I'm far from proficient, so I thought it might be interesting to write about my experiences from that angle.
Subscribe to:
Posts (Atom)