As James pointed out recently the AD Web Service from Windows 2008 R2 has been released for Windows 2008 and Windows 2003 - see http://blogs.msdn.com/adpowershell/archive/2009/06/23/use-active-directory-powershell-to-manage-windows-2003-2008-dcs.aspx for details.
Having installed it there doesn’t appear to be any sign of the AD cmdlets or Provider. On this basis it is useless. If anyone knows different please let me know because I’ve looked in all the logical (and illogical) and I can’t find those cmdlets. The Windows 2008 R2 RSAT won’t install so that source doesn’t work.
I went on to the Microsoft site looking for books on SQL Server 2008. What you get is an incomprehensible jumble of stuff. Don’t tell me about everything there is – let me get to the information I want.
I used to really like the Microsoft site as there was masses of information that usually logically arranged. Now we get some many layers between us and the information that I’m likely to expire of old age (OK I know its not that long to go) before finding it.
Another example – I went looking for the information on the SQL Server exams – the logical route through the site leaves you with the impression there isn’t an upgrade from SQL 2005 MCITP to the 2008 version. Wrong! But oh how you have to search.
I’m coming to the conclusion that the only way to access the Microsoft site is to search from outside and hope you can get to what you need.
A triumph of style over substance at the moment.
Buck Woody blogged about SQL Server autoclose and how it should be set to being off - http://blogs.msdn.com/buckwoody/archive/2009/06/24/sql-server-best-practices-autoclose-should-be-off.aspx
I’m doing a lot with SQL Server and PowerShell at the moment and it started me thinking that I could easily set this property in PowerShell.
Create a server object and display the databases, selecting name and the autoclose property. Its boolean so we get true or false back.
We can iterate through the database collection. Test if the database is a system database and set autoclose to false (we don’t want autoclose to happen). A call to Alter() saves the change.
Finally we can recreate the server object and redisplay the autoclose property.
The PowerShell team want to know how you find PowerShell related material – scripts, training material etc etc
I’ve noticed the way foreach is being used and it falls into two groups. I am using foreach-object to keep the discussion straight – like everyone else I use the foreach alias – yes I know I rant about aliases but the aliases for the *-object cmdlets make sense.
The first one reads the file and then iterates through the objects while second one reads the file and puts the objects on the pipeline.
So whats the difference and is it a big deal? Instinctively I try to use the second but is that best?
using foreach we have to read the file and hold all the objects in memory while the foreach-object works with them one at a time as they come down the pipeline – for a big file that makes a lot of difference in resources. However, if we need to access a file multiple times using foreach may be the better option as we only have to read the file once. foreach can be faster which is a trade off we may need to think about
inside the loops we can use $thing or $_ to access the object respectively. One point to think about is that if you do further work inside the loop that generates a different $_ eg a switch then reading the code may get confusing especially if you come back to it after a while
So is there a best option – probably not as an all time categorical “this is the best so always use it”
I tend to prefer the foreach-object as I can get on with processing objects straightaway though we do have to be careful with subsequent order of events sometimes. The other advantage is that foreach-object gives me a –begin, –process and –end script block which makes things even more flexible
So no hard and fast answer but as a final thought the foreach-object usage looks more “powershelly” as someone once put it
I have always been impressed by by Quest’s AD Recovery Manager and now its even better – yep it has PowerShell cmdlets see http://wiki.powergui.org/index.php/Quest_Recovery_Manager_for_Active_Directory_cmdlets_reference
Beginners – find the errors in the script
Advanced – read a text file of a network trace and find the delay
can’t be bothered.
Beginners was done last year plus I really hate scripts that have $objxxx - so VBScript
Advanced is yet another variation on reading a file.
Advanced – write a script to play 21 or blackjack or pontoon or whatever you want to call it. Did that last year see http://richardsiddaway.spaces.live.com/blog/cns!43CFA46A74CF3E96!1161.entry
Might have a look at beginners 7
Read a file and create a graph of the results. The quickest way to graph the data is to take the height and display a number of “*” depending on the value.
-split is a PowerShell 2 operator - use $_.Split(“,”) in v1
BTW – there are 43 jumps per person not the 30 as stated in the event information.
This answers the letter of the event but probably not the spirit. PowerGadgets would be an interesting option for this. PowerGadgets installs straight into Windows 7. I had tested it with PowerShell v2 in the past but nice that it installs on Windows 7.
If we want to create individual graphs using PowerGadgets
All we do is pipe numeric data (notice the double split – the first gives the names plus the numbers as one string. We can then split the numbers separately as required) into out-chart using the first two elements from the first split (jumpers name) as the title.
Finally lets look at charting in Excel – we have to use the COM object to work with Excel (wouldn’t be nice if we got proper PowerShell support in next version of Office – please - )
We create a spreadsheet and add a work book . Have to use this long winded method as I am using a non-US culture on my machine (Excel bug).
We can add the work sheet, add the data and finally add the chart. Chart looks ugly but it is a chart. Finally save the spreadsheet using the same horrible construction.
didn’t like this event - tedious