If you experience WMI problems (like I currently do – put operations to WMI combined with Live Communications Server 2005 fails – but not always), give the WMI Diagnosis Utility v2.0 go try. Get it here.
A new feature of R2 is the ability to manage hardware through something called WS-Management. WS-Management uses the WS-* Web Service architecture to support a consistent method for remote management of devices (e.g. servers). It does this by exposing a set of functionalities to consume hardware management information on top of the Intelligent Platform Management Interface (IPMI). In addition to hardware it also interfaces with WMI so you can accomplish management tasks both through IPMI-enabled devices and WMI.Functions exposed are Read and Set information. Execute methods, create and delete objects and retrieve collections of objects. By default it uses certificate-based authentication but R2 also provides basic authentication (over SSL of course).
An example would be enabling Remote Desktops through wsman as I’ve demonstrated earlier through WMI and through the registry -
wsman invoke http://schemas.microsoft.com/wsman/2005/
02/wmi/cimv2/Win32_TerminalServiceSetting?
ServerName=HOSTNAME -machine:FQDN @{AllowTSConnections=”1″}
(Wrapped for readability)
The wsman command line tool itself is actually a script, so you can use this as a basis for your own scripts, furthermore it “only” needs port 443 open on the target system.
For more information check out the TechNet scriptcenter article or this whitepaper.
This week, I was out on an oil rig in the North Sea helping out in some fail-over testing. After the test, I had to collect eventlogs from all the computers involved and as I’m an scripting guy, I definitely did not want to do that manually. Now, this is a Windows Server 2003 and Windows XP environment. Furthermore, it is a highly restricted environment so I could not install PowerShell or plug in and use my own PC; I had to look elsewhere. First, I looked at Sysinternals’s psloglist, but that could not do the job. It could either dump the eventlogs as text – I wanted binary – or it could dump as binary and empty the logs at the same time. I only wanted a backup. Next, I googled and live searched, but did not really find anything useful, when my old fried WMIC resurfaced in my mind. Wasn’t there some method call in WMI, that could do the job?
Using my own PC, I could easily find the method. It was just a matter of writing gwmi win32_nt, pressing tab (as I naturally use PowerTab), selecting win32_NTEventlogFile and piping it into Get-Member -
gwmi win32_nteventlogfile | gm
And the method BackupEventlog showed up. I started wbemtest on a Windows XP PC and checked that the method also existed on Windows XP. After this, I started to figure out the WMIC command line – which quite often is hard to get right. I ended up with -
wmic /node:"server" nteventlog where "logfilename='system'" call backupeventlog "c:\system.evt"
Note, that the backup file specification is local to the remote node. I tried saving it back on the local PC with \\currentpc, but got access denied and I did not want to create a share for this. Also note that the WMIC alias for Win32_NTEventlogfile is NTEVENTLOG
Finally, I ended up with this backup.bat file. All.txt contains a list of the computers, I needed to get the logs from. Note that I delete the evt-files first as backupeventlog will not overwrite an existing file (if I needed to re-run the script)
set targetdir=%temp%\logs for /f %%I in (all.txt) do del \\%%I\c$\*.evt for /f %%I in (all.txt) do wmic /NODE:"%%I" nteventlog where "logfilename='system'" call backupeventlog "c:\system.evt" for /f %%I in (all.txt) do wmic /NODE:"%%I" nteventlog where "logfilename='security'" call backupeventlog "c:\security.evt" for /f %%I in (all.txt) do wmic /NODE:"%%I" nteventlog where "logfilename='application'" call backupeventlog "c:\application.evt" for /f %%I in (all.txt) do robocopy \\%%I\c$ %targetdir%\%%I *.evt /z /njs /njh for /f %%I in (all.txt) do del \\%%I\c$\*.evt
OK – so now you’ve setup your Live Communications Server environment and login to Office Communicator 2005 or Windows Messenger just to see an empty list of users. Then the next questions come into mind – how do you populate users?
In Inceptio we initially used dsquery and some of the scripts that are part of the LCS 2005 SP1 Resource Kit.
First of I used dsquery to create a file with contacts (Check dsquery /? for further commands e.g. for traversing more OU’s)
dsquery * “OU=Users,OU=Inceptio,DC=domain,DC=com” -attr msRTCSIP-PrimaryUserAddress -filter (msRTCSIP-UserEnabled=TRUE) > contacts.txt
Then I used the LCSAddcontacts.wsf script that will add contacts to a list of LCS users (The contacts.txt created earlier) – the script can be found in “%Programfiles%\Microsoft LC 2005\ResKit\WMI Samples” and information on the use can be found in LCSAddcontacts_readme.htm file
CScript LCSAddContacts.wsf /usersfile:contacts.txt /contactsfile:contacts.txt /contactsgroup:Inceptio
As you can se I use the same file twice for both the user and contact list, thereby adding all users to all users contacts list (Thanks to Ray Breen / Google for this trick).
Then I need to auto allow the users. This is (in my case) easily done by using LCSAddACEs.wsf (Also from the reskit)
CScript LCSAddACEs.wsf /usersfile:contacts.txt /acesfile:Acesfile.txt
I reuse the same contacts.txt file used earlier, but I now use also use an Acesfile.txt file containing the following text (Notice that Allow, Prompt, Block and Deny are case sensitive) -
domain inceptio.dk Allow Allow
As we are a small consulting company there is no problem in auto allowing all users to see each other, I recognize that this will not be useful in most larger companies (Certainly not in our customers), in these cases I would manipulate the contacts.txt file to create a new file looking like this -
user: sip:alice@inceptio.dk Allow Allow
user: sip:bob@inceptio.dk Allow Allow
etc.
I would not recommend using All Allow Allow as acesfile.txt input as it also gives All Other Contacts allow rights (Instead of notifying as usual), which probably isn’t a desirable behavior for PIC or Federation contacts.
The above is just an example of how to use the sample scripts to populate users. It would be a good idea to join and refine the scripts into a single script taking e.g. OU or AD Group as input and then populating organization groups etc. with each other contacts.
Btw. the above scripts should be run from the LCS Home Server
In his last post of 2006 (the first of 2007 in my timezone, does this guy never sleep?) Jeffry Snover, PowerShell Architect, posted a very good and precise description of why PowerShell is so important. The core of this is the Admin Development Model and I have extracted the most important part here as I think this explains it so good -
One of the things that motivated us to develop PowerShell was the belief that we (Microsoft) had been doing a poor job supporting the Admin Development Model.
All the effort seemed to have gone into treating Admins as GUI-only users or as though they were developers that couldn’t handle the complexity of parenthesis. I never quite understood the thinking there. On the one hand, you expect the admin to comprehend the mind-numbing complexity of WMI and ADSI but on the other hand, you invest in a language that allows them to avoid typing the parentheses in an IF statement? Was that really the problem? Don’t get me wrong – for what it is, VBScript is great but at the end of the day, a lot of VBScripting is full blown systems programming with a simplier syntax. There is nothing wrong with that. The vast majority of Admins are super smart folks that can do systems programming WHEN THEY HAVE THE TIME TO.
Therein lies the problem. Systems programming takes a lot of time and effort and is pretty formal. The Admins I know don’t have a lot of spare time because they run around with their hair on fire. When your hair is on fire, you need a bucket of water and systems programming is not that bucket of water. What admins need is a set of tools that match the reality of their work. Admins need an interactive shell.
An interactive shell that allows them to quickly, easily, and iteratively investigate and manipulate their systems. Since the nature of admin problems/issues change constantly, they need to easily compose solutions by leveraging a set of base, domain-specific, commands and a then set of powerful, domain-independent, utility cmds. Bruce Payette once said something to the effect that, “the lifespan of 95% of the scripts in the world start at the prompt and end at the carriage return”.
Once you have an interactive shell that supports great compositional scripting, then, depending upon the problem and the odds that you’ll want to do that operation again, Admins save that script into a file and run it instead of having to figure it out/type it every time. Over time, they may decide to generalize the script so that it can deal with more and more situations. Later they may choose to make it more formal and do better error handling. Sometimes, they’ll want to make it part of their formal management of production servers at which point they’ll want it to be very formal, leveraging types/constraints, rich error handling, digital signatures and all that.
This range of activities, from interactive shell, to quick and dirty scripting, to formal production scripting is what we call the Admin Development Model. (Note that model of work is NOT limited to Admins – many people use this but it is critical for Admins.) PowerShell is very focused on supporting the Admin Development Model. That is why we have an interactive shell.
That is why we struggled hard to find the right balance in our syntax and semantics between interactivity and scriptability. That is why we support
a wide range of scripting styles from quick and dirty (bash-style) scripting to more advanced (Perl-style) scripting to more formal .NET programming. We wanted to ensure that you could learn a single tool and then decide how you were going to use that tool to solve the particular problem at hand.It is NOT the case that beginners will do the simple stuff and experts will do the sophisticated stuff. We expect everyone will do do everything at some point in time – it is question of the problem they are trying to solve and the skills they have at the moment. (e.g. The highest end of scripters are still going write lots of quick and dirty, ad hoc scripts – because that is the right tool for lots of situations.).
The great thing about having a single tool to do this is that it becomes economical
to invest in learning the capabilities of the tool because it can be leveraged in so many situations. It also increases the pool of people that form the community that help each other solve problems. It also makes it easier to grow your career, as you gain expertise and become more productive and opens up more job opportunities than expertise in a very narrow toolset provides (this is another reason why we leveraged .NET – learning .NET makes you more marketable. If you are a hiring manager leveraging PowerShell – the job is more attractive to people and there is a larger pool of experienced people to hire from.)PowerShell supports the Admin Development Model because it allows PowerShell to be the right tool for the right job for the maximal range of problems and lays the groundwork for a large and vibrant ecosystem.
- Jeffry Snover
During the last couple of months I’ve spent quite some time on getting the grips on PowerShell (PS). As written earlier, PowerShell will be important, but expect it to take some time and effort to get it ‘in the fingers’.
When you first look at it, you may ask yourself – hey – what’s the big news in the examples you see? Most things can easily be done with other well-known tools. What so funny about – say – creating 10 folders -
PS> 1..10 % { md folder$_ }
when I could do it with
CMD> for /l %i in (1,1,10) do md folder%i
And what is the big advantage in starting a service with
PS> start-service bits
when I could do it with
CMD> net start bits
Of course, restart is nicer
PS> restart-service bits
But this does the job as well
CMD> net stop bits & net start bits
But as you start try to do REAL stuff you realize the potential. How about keeping the logs for the last 10 days, named with the date? That is not easy at all with CMD and I often created an self-contained script to do the job -
CMD> set script=%temp%\x.vbs
CMD> echo script line 1 > %script%
CMD> echo script line 2 >> %script%
CMD> cscript %script%
With PS you can do it right away with code like -
PS> $logbase=”$env:temp\my.log”
PS> $fivedaysold=$logbase+[system.datetime]::now.adddays(-5).tostring(”yyyyMMdd”)
PS> $fivedaysold
D:\DOCUME~1\user\LOCALS~1\Temp\my.log20060730
So, if you want to learn PS, do not just use it once in a while. Expect that you will spent much time on learning it – but stop using CMD as much as possible and realize that you can combine all your tricks and (programming) skills by combining command line stuff with COM, WMI and .Net stuff – right from the command line. In this way, you will learn along the way.
Be powershelled yourself!
