|
|
-
The development team for iSCSI has released some more information about WMI and iSCSI devices. Getting this information should be very easy under Windows 2008.
|
-
I have been using the PowerGUI Script Editor, version 1.5.2.550, from our partners at Quest Software (download it here).
It gives me nice syntax highlighting, and a big button to run the script, just like in Visual Studio. Quest offers a number of special cmdlets for ADSI, but I haven't tried any of those.
One of the nice things about PowerShell is that it offers lots of ways to do things. For example, if you are trying to count occurences of some structures using Perl, you certainly can use regular expressions. However, if you grew up thinking in terms of how the DOS matching engine works, you can do a lot (though not everything) with simpler patterns. Consider this little script:
Set-Location C:\Users\me\Desktop\test
foreach ($log in Get-ChildItem -literalPath C:\Users\me\Desktop\test){
$pusg =$pgsg=$plsq=$husg=$hgsg=$hlsg=$wkn=0
switch -wildcard -file $log {
"*Primary SID*Universal Security Group*" {$pusg++}
"*Primary SID*Global Security Group*" {$pgsg++}
"*Primary SID*Local Security Group*" {$plsg++}
"*SID History SID*Universal Security Group*" {$husg++}
"*SID History SID*Global Security Group*" {$hgsg++}
"*SID History SID*Local Security Group*" {$hlsg++}
"*WellKnown*" {$wkn++}}
write-output "$pusg $pgsg $plsq $husg $hgsg $hlsg $wkn"
}
The Desktop\test directory contained a bunch of output files from ntdsutil, created with that utilities own language and batch files. Now, rather than rewriting the wheel to get to that point, start from what you have (a bunch of files) and read those files in order to get the statistics you need for estimating problems in domain migration. The script above produces one row per file, counting the entries in the output that match certain criteria.
If a line in the input file contains the words "WellKnown", for example, increment the $wkn variable by one -- and that total will be in the 7th value from the left in the output row for that input file.
I've seen some terrible and unmaintainable tools for doing this sort of meta-log processing, particularly in certain industries, and you can't beat being able to quickly modify a rule in the GUI, and generate your statistics. Plus, you have certain guarantees from theoretical computer science about the run times of routines coded in this fashion.
|
-
The philosopher Leibniz placed the windowless monad at the core of his philosophy -- we are such things, preprogrammed in such a way that everything will work out properly, and we will not run into puzzles arising from the interaction of mind and matter. What a perfect code name, then, for the PowerShell language. The Powershell team blogs extensively; what I want to address today are some good books on PowerShell.
Tyson's Kopcynski's Windows PowerShell Unleashed is a short 306 page volume that spends the first third of the book helping the reader distinguish what a shell and a shell language does as distinct from a general purpose programming language. It has a good discussion of code signing, which may be the number one reason that PowerShell will ultimately triumph over vbs scripts and the like in your environment -- only the code you know and trust will run. The second third of the book discusses file, registry, WMI, and Active Directory manipulations from within PowerShell. He uses screenshots (white on black) extensively, which reduces the readibility of his text. The last part of the book is a real gem, a discussion of the cmdlets (commands in Powershell) that ship with Exchange. Anything you can do from the GUI in Exchange, you should be able to do with these cmdlets. My review is based on the first edition, and the link is to the O'Reilly Safari edition.
If you have to teach a class on the subject, I would say that Kopcynski's book is the best of the three I discuss -- I used Cobol Unleashed (a much larger tome) to this end many years ago.
An excellent reference is Ed Wilson's Windows PowerShell Scripting Guide, a fat 663 page volume from Microsoft Press. Ed has written extensively on WMI. If you have something you need to administer beyond the basics (such as the certificate store, or cluster services, or deployment), you probably should have a copy of this book. It comes with an electronic version of the book on disk, and seems to be available at discounted prices.
My colleagues consider Bruce Payette's Windows PowerShell in Action to be the best PowerShell book. Certainly, if you need to understand metaprogramming in PowerShell, and how to create your own cmdlets, it is where you need to go. However, for most customers (particularly those without any academic background or interest in computer science), there are many things that are rough going, and it is hard to get a sense of what's the case 99% of the time, and what is just an outlier.
|
-
-
I needed a program that could do layers and web graphics. I found this: http://www.getpaint.net/ -- Paint.net, a Microsoft mentored senior design project. It is open source. It is very fast. And I think I'm going to like it more than Photoshop. Of course, it doesn't do CMYK colorspaces and the like, but without color swatches, that doesn't help much with putting out print materials.
|
-
I have determined my topic for my first training triage: "Writing a WMI Instance Provider". Since everyone in the training will be on a corporate network, I have a wide variety of tools available to make the presentation an interesting one.
Notably, one of the things I'd like to do is have a series of interactive polls and quizzes as I move through the different parts of the presentation. I think that there is probably some really good way to create such a learning object. I did some work on SCORM compliant learning objects in my past, but I'm not sure how far Microsoft has gone in that direction, or whether or not I should basically author things within Powerpoint, or whether I should create something in Sharepoint. More on this tomorrow.
|
-
Suppose you have an application running on a customer's machine. They inform you that the application has been unable to create something, or unable to read something. You suspect some kind of issue with the permissions the program has to read or write, but aren't sure what is being read or written. The security logs are no help; developers have to explicitly enable that logging, even if you have turned on maximum logging.
You could fire up a user mode debugger, like windbg, load symbols, and try to figure out where it is failing. However, a much, much easier method is to log the file and registry activity between the program and the operating system. This is where the tool http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx Process Monitor comes into play. Just run the executable, and look at the activity filtered by your running process.
|
-
From the earliest days of Windows NT, even before Active Directory was on the scene, every process has an associated security token. To see the information contained in the token, if you are using the windbg debugger, you can use the !token meta-command, and that will give you such things as the list of security group with which the account is associated. If you are running Windows 2008 Server, though (or have installed the appropriate tools), you can see this information by using the whoami /all command at the command line.
The token bloat problem is an old one. I've heard about them going back into the last century. If you have a fixed-sized buffer in which to pass a token, and the token has more groups than will fit in that fixed-sized buffer, it is a bloated token. Things will then fail if the API that the token is being passed to needs part of the token that isn't in the buffer.
So, how do tokens become bloated? By the addition of new security groups. There are companies that have nearly a hundred security groups associated with a single user. That seems excessive, but if you have been running Windows since 1994, and you add a new security groups a month, every month, that is over 150 groups!
One possible solution is to change the size of the buffers (an excellent discussion of that solution is here: http://support.microsoft.com/kb/263693). In that case, though, you will be changing the buffer size not just on client machines,but on the domain controllers and the servers as well. In an organization that has been using Windows since the mid-1990's, this can mean rebooting fifty thousand computers. No one wants to do that.
The solution that makes more sense in practice is to take a hard look at that list of things added to that token over the years. You probably don't need your membership in the Y2K Remediation Group anymore, for example. The Enron Account managers group would also probably not be that useful.
Every choice of a buffer size is a engineering tradeoff, just as 2 digit dates were a reasonable choice when we talked about dollars per byte rather than dollars per megabyte or gigabyte for memory costs. The default is a reasonably good one in a well-maintained Active Directory Security Infrastructure.
Ever had this kind of issue? How did you figure it out? Comment and let me know.
|
-
WMI, or Windows Management Instrumentation, is the standard method used by Windows to monitor and control services on network computers.
Perhaps the first place to go to learn about WMI is the Wikipedia (http://en.wikipedia.org/wiki/Windows_Management_Instrumentation). I'm been a bit active on Wikipedia since I was teaching at UNCC here in Charlotte. Always make sure you look at the edit history (or simply glance at the edit history) to make sure you haven't wandered into a heated debate. One reason I suggest that rather than our own resources is this: suppose I were to make a pointer to the standard page out of the MSDN online documentation (http://msdn.microsoft.com/en-us/library/aa394582.aspx). What happens to my link when MSDN is rearranged? There certainly are links at the bottom of the wiki article to the standard references, but unlike my link, a team of people will update those links when they become stale.
However, when it comes to books on the subject, my first place would be the Windows Internals book by Dr. R, one of our Microsoft technical fellows (with David Solomon)-- http://technet.microsoft.com/en-us/sysinternals/bb963901.aspx. In about ten pages, he carefully defines the important terms and introduces you to the most important tools for browsing the repository and calling into WMI. The 5th edition (covering Windows 2008 Server) is expected to be published in January of 2009.
When I came to the DSC-Manage team, my predecessor left me two very good books. Wes recommended the New Riders WMI: Windows Management Instrumentation book (by Lavy and Meggitt, (2002)). Lavy has a MPhil from Cambridge, so I was right at home. If you are a system administrator, then this is the book for you. However, it doesn't go into the details of actually writing a provider, and I think it insufficiently warns the reader about the huge performance hit your programs take in doing ADSI tasks from WMI.
The other volume I have is from Addison and Wesley, Developing WMI Solutions: A Guide to Windows Management Instrumentation (2003). That is the book that one needs to use if one is writing a provider (though really complex providers will involve looking at something like Robbins' book on writing device drivers). Wes thought that this book spent a bit too much time dwelling on theoretical topics (there is a chapter about UML, for instance).
Next week, I want to talk about an actual problem I've run into working with a large customer -- the problem of token bloat -- and put it in the context of making decisions about the allocation of structures for an API.
|
-
Noticed that people are already seeing this blog ... that is certainly interesting.
Different people learn in different ways. Some people learn by experimenting with a technology. Some learn by formulating different search queries to their favorite search engines. Some learn by watching others. I've always been one to learn by reading books. Books are different than KB articles. They typically are infused with the voice of a particular author.
In working on my last technology, Certificate Lifecycle Manager and Identity Lifecycle Manager, I didn't have the benefit of many written resources. What few I saw were:
The Active Directory Cookbook, 2nd edition http://robbieallen.com/blog/adcookbook/index.html which discussed MIIS.
Morimoto's Exchange Server 2007 Unleashed http://www.amazon.com/Microsoft-Exchange-Server-2007-Unleashed/dp/0672329204 has a good discussion of Galsync and also discusses some of the other MA's (Lotus Notes, I think).
Most of the resources were blogs:
Calderon's blog: http://blog.identityjunkie.com/2007/06/learning-microsoft-identity-management_04.html is a good source of the links needed to learn identity management.
However, in the ADSI/WMI space, there are lots and lots of written documents.
I started with the Kaplan and Dunn book, The .NET Developer's Guide to Directory Services Programming (2006), which does a fairly good job of explaining how to use the System.DirectoryServices namespace, and touches upon the System.DirectoryServices.Protocols namespace as well. My friend Tim MacCaulay, who is as crazy about books as I am, gave me a copy when we essentially switched teams (he's on the DSC-Identity team now).
The classic book about ADSI (which stands for Active [Directory Services Interface], not Active Directory [Services Interface] -- it can be used against many things other than Active Directory) is Simon Robinson's book, Professional ADSI Programming from Wrox Press (1999). My colleague Joe Cordero gave me a copy of that 800 page monster. Though there are a number of things in that volume that are quite dated, if you are writing a provider, and using ATL (the active template library), there really isn't a better reference. In my serious COM days, I used a lot of MFC (Microsoft Foundation Classes), and never really worked much with ATL, so having a good explanation was for me a must.
Another senior engineer here in North Carolina, David deGroot, used the Oppermann volume, Microsoft Windows 2000 Active Directory Programming (2001) as his vade mecum when he was on the ADSI team. If you are coming into an environment with lots of vbs scripts that perform all kinds of administrative operations, and you don't know a thing about writing VB Script code, this is the book for you.
Of course, for a variety of security reasons (I was at Microsoft during the http://en.wikipedia.org/wiki/ILOVEYOU virus epidemic), vbs scripts are often discouraged these days. Powershell scripts (which can be signed) are a better way to make ADSI calls. More on that later.
|
-
My name is Drew Arrowood, and I am the newest engineer on the ADSI/WMI/Cluster Services/Powershell team. I'm located in Charlotte, North Carolina, Microsoft's largest East Coast location, which happens to be off Arrowood road.
This isn't my first team at Microsoft. I've worked on Windows installer issues, and I've also worked on identity management. However, this is my first Microsoft blog. I was inspired by a lot of the good blogging work done by our Exchange engineers here in North Carolina.
The first thing I'm going to be doing is a short review of some of the published resources on our technologies.
|
|
|
|
