Discovery in the Dark of Night

Dr. John H. Watson, if not as highly deductive as his friend Sherlock Holmes, was certainly diligent enough to make some significant discoveries. Imagine if your messaging platform  could be such a trusty partner and find messages matching certain patterns in the dark of night and save the results for you when you needed them.

Exchange Server 2010 supports searching any number of mailboxes, from one to the total number of mailboxes in the Exchange organization, for particular content patterns. This type of multi-mailbox search, called a Discovery Search, can do its work while you are sleeping, and the results are stored in a special type of mailbox called a Discovery Search Mailbox. Therefore, prior to issuing a discovery search request, you should first create a discovery search mailbox to hold the search results.

When you install Exchange Server 2010, the setup program creates one discovery mailbox for your convenience. Prior to performing a discovery search, you can choose to use this or any other discovery mailbox you have created earlier. Or you could use the Exchange Management Shell (EMS) to create a new discovery mailbox. To create a new discovery mailbox, simply run the New-Mailbox cmdlet in the shell with the -Discovery parameter. The discovery mailbox must be stored on an Exchange Server 2010 server hosting the Mailbox role.

Part of the idea behind discovery mailboxes is that you can execute multiple searches and have the results saved in different mailboxes. Extending this concept beyond one administrator or other person delegated the discovery search capability, multiple people can perform their own discovery searches to meet their own goals. Each person can have their own collection of one or more discovery mailboxes that they use to store their results independent of the others.

Another aspect of discovery mailboxes which is important is that, like ordinary user, room, and equipment mailboxes, each discovery mailbox is hosted by a particular mailbox database on your Exchange servers. Each discovery mailbox also has its own quota, which defaults to 50 GB of search results. In addition, each discovery mailbox has permissions which can be assigned to it which govern who can look at the search results, among other allowances.

Discovery search requests can be initiated with either the EMS cmdlet New-MailboxSearch or using the Outlook Web App (OWA) hosted Exchange Control Panel (ECP). Once a request has been created, it can be paused or resumed using the EMS Stop-MailboxSearch or Start-MailboxSearch cmdlets, or via the web-based ECP. The search criteria or source mailboxes could also be modified using the Set-MailboxSearch cmdlet or ECP rather than needing to delete the old request using a Remove operation then a New (create) operation again.

The requester may view the results of the search as soon as they are complete, or could wait to view them until a later date. Like other mailboxes hosted by Exchange Server 2010, the discovery mailboxes could be placed on litigation (legal) hold for retention.  Note that only mailboxes which are hosted on Exchange Server 2010 servers with the mailbox role are searched. Exchange Server 2007 mailboxes, Exchange Server 2003 mailboxes, and personal folder storage (PST) files are not searched using the Exchange Server 2010 multi-mailbox search feature. Again, the discovery mailboxes which store the search results must also be hosted by Exchange Server 2010.

Discovery (multi-mailbox) searches and the discovery mailboxes which support them are a great capability of Exchange Server 2010. How would you use this feature?

A Tale of Two Scripties — Start-Demo and ISE



At the shell prompt, Windows PowerShell lets us run a single line at a time interactively. When we invoke a function or script, the whole thing runs. It doesn’t have to be an all-or-nothing proposition.

Circa 2007, Jeffrey Snover, Microsoft’s chief powershell architect, posted a function called Start-Demo which allows the user to choose lines of a script to execute, which ones to skip, and allows inspection and adjustments of variables and other data in the middle of a script. I started using a new and improved version of his Start-Demo function, and eventually modified it in several ways, including the ability to replay history, easily demonstrate any of Get-Help’s examples, and work with scripts including assignments and other complexities which the earlier versions didn’t support. Now, a couple of years later, I have just discovered that Joel Bennett had also customized Start-Demo around the same time, also adding support for assignment operators, and adding other great features such as key-by-key interaction commands. We’ll look at a comparison of these different versions later.

Many presenters and instructors used one or another of these versions of Start-Demo to help teach PowerShell step-by-step. Some people used it for troubleshooting and debugging of scripts. My version of Start-Demo is included in Microsoft Official Course 6434 “Automating Windows Server 2008 Administration with Windows PowerShell” along with about 160 demo scripts and 65 or so other example scripts for instructors and students to use in that course. Just this week I again had the great joy of teaching this class and used Start-Demo extensively throughout.

But times, they are a changin’. True, I’ve thought many times about updating Start-Demo with new fixes and features, but at the moment, I’m referring to something completely different.

Now, in the last quarter of 2009, Windows PowerShell version 2.0 (PoShV2) has released with many features, including two features related to Start-Demo. So is Start-Demo obsolete now that there’s a new sheriff in town? Let’s look at two features of PoShV2 and you can decide.

First, we have the alternative to running PowerShell in a simple console host (conhost.exe) which still makes it look very much a classic Command Prompt (cmd.exe). Yes, this alternative is PowerShell ISE, the Integrated Scripting Environment which Microsoft included with PoShV2 and which I have been blogging about. You can quickly type <Ctrl>+O to open a script file in the script pane (or you can use menus if you’re into that kind of thing). Once you have the file in the script pane, you can select a word, line, code block, or function declaration using the mouse or <Shift>+arrow keys. Then to run just that selected code snippet, type <F8> or use the Run Selection icon in the toolbar. Yes, instead of using <Ctrl>+A then <F8> to select all then run selection, you could simply type <F5> to run the whole script.

It is possible to select a line of the script at a time (hint: <Shift>+DownArrow), then use <F5> to run each line. Caveat coder: Complete code blocks or statements should be run as a unit (think: match those curly braces). But there is another variation on this theme. You could use breakpoints – start by selecting the first line, and typing <F9> to toggle (enable at first) a breakpoint on this line. Then if you just use <F5> to run the whole script, execution will halt and the debugger will be invoked. Real coverage of the debugger is food for another blog article.

But before we go, it’s worth closing with yet another variation on a theme – in this case, the theme of debugging and breakpoints. Even without ISE, in a regular PoShV2 window, this new version of PowerShell is armed with cmdlets such as Set-PSDebug, Set-PSBreakPoint, and help topics such as about_Debuggers. That too is fuel for another fire… blog post.

Until then, take care, and make sure you download PowerShell version 2.0 for Windows XP, Server 2003, Vista, Server 2008 if you haven’t hopped on the Windows 7 or Windows Server 2008 R2 bandwagon just yet.

Let Them Eat Cake… or Windows PowerShell version 2.0



PowerShell version 2.0 for the masses. Yes, the time has come.

After many Community Technology Preview (CTP) pre-releases, Windows PowerShell version 2.0 shipped with Windows 7 and Windows Server 2008 R2. Now, finally we have a package available for download from Microsoft to get PowerShell version two for Windows XP, Vista, Server 2003, and Server 2008 as well. Thanks to Mike Roberts for mentioning this to me, and to John D. Cook for blogging about it, and of course to Microsoft for the release page on TechNet.

As Mr. Cook noted in his blog, this is part of the Windows Management Framework (WMF) for XP, Server 2003, Vista, and Server 2008. As the TechNet article can tell you, this includes three things.

  1.   Windows Remote Management (WinRM) 2.0
  2.     Windows PowerShell 2.0
  3.     Background Intelligent Transfer Service (BITS) 4.0

Why is this significant? As much as it would be exciting to talk about PowerShell first, we’ll save the best for last. Let’s start with BITS.

The Background Intelligent Transfer Service (BITS) has been around since the early days of Windows XP and Windows Server 2003. There’s a nice compact BITS history at Wikpedia. One of the places in which BITS is used in Windows networks is for the Windows Server Update Services (WSUS) and the corresponding Windows Update Automatic Updates (WUAU) service. The new version 4.0 of BITS supports an enhanced security model, better network-friendly performance, enhanced tunability, and a BITS Compact Server implementation in Windows Server 2008 R2.

Windows Remote Management (WinRM) is Microsoft’s implementation of the industry standard Web Services Management (WS-Management) framework which is a part of a larger set of web services interoperability standards. Fundamentally, WinRM and other non-Microsoft implementations of WS-Management use the extensible markup language (XML)  to represent object-oriented method requests sent over the hypertext transfer protocol (HTTP) to software objects on (potentially) remote computers/devices. The industry standard for this particular OO method request/response over XML/HTTP is called the Simple Object Access Protocol (SOAP), and an earlier version of SOAP was implemented in Windows Server 2003 with IIS 6.0. Then WinRM and other web services grew up around that foundation. In a sense, increasing popularity of web services, SOAP, and WinRM in Windows represent an evolving humongous long-term shift away from dependence on the classic Remote Procedure Call (RPC) historically (and still) used in so many Windows subsystems. But aside from other web services on the Windows platform, WinRM specifically means a great deal with respect to Windows management in general, and moreover to PowerShell remoting.

And thus, all roads lead to PowerShell. One of the great advances of PowerShell version 2.0 beyond version 1.0 is that WinRM and PowerShell “Remoting” are built-in. In fact, the remoting is built in so intrinsically that compared with the Exchange Server 2007 Exchange Management Shell (EMS), Exchange Server 2010’s EMS looks completely foreign at first glance. There’s no need to panic – it’s simply that the guts of how EMS does its work is radically different in E2010 with PowerShell v2.0 under the hood and loads of functions instead of cmdlets, all with remoting at their heart.

But taking PowerShell v2.0 beyond the comfortable home of Windows 7 and Windows Server 2008 R2 and enabling it to be used directly on Windows XP, Server 2003, Vista, and Server 2008 is where the fun begins for everyone else who is not on the leading edge. Better than icing on the cake.

* “shell soap” image borrowed from here.

Fine-Grained Password Policies — password settings objects


Windows Server 2008 supports Fine-Grained Password Policies in Active Directory, which is a huge step forward from the per-domain-only password policies of Windows Server 2003 and Windows 2000 Server Active Directory. Yet with the suggested built-in management interface for creating fine-grained policies being ADSIedit, LDIFDE, and similar utilities, and with the requirement that the Active Directory domain in question be at the Windows Server 2008 domain functional level (DFL), such policies aren’t yet deployed as widely as some people might hope.

In this article we’ll review the functionality and objects involved in fine-grained password policies (FGPP). In a subsequent article, we’ll present the use of the Windows Server 2008 R2 PowerShell v2.0 cmdlets for working with fine-grained password policies.

The Windows Server 2008 (W2K8) Active Directory schema contains some new object classes and attribute types to support fine-grained password policies. With W2K8 AD, an instance of one of these classes, a password settings container is created in the domain’s System container. In fact, the name of this container in the domain would be:

CN=Password Settings Container,CN=System,DC=777,DC=wernerconsulting,DC=com

With the Advanced Features view option enabled in Active Directory Users and Computers (ADUC), we can see this container and if there are any policies defined in it, we could work with their properties in ADUC’s Attribute Editor. But to create the Password Settings objects which go in that container, we could use ADSIedit, LDIFDE, or other tools. Once created, we could use those same tools to view and edit the settings, or we could come back to ADUC and use the Attribute Editor. In another article, we’ll see some PowerShell cmdlets in W2K8 R2 which offer an alternative.

Let’s look at a Password Settings object – the object class is msDS-PasswordSettings. Although these can be created in ADSIedit and then modified in ADUC, let’s see one in standard LDIF format.

dn: CN=Sales Password Policy,CN=Password Settings Container,CN=System,DC=777,DC=wernerconsulting,DC=com

objectClass: msDS-PasswordSettings

cn: Sales Password Policy

msDS-MaximumPasswordAge: -18144000000000

msDS-MinimumPasswordAge: -6048000000000

msDS-MinimumPasswordLength: 16

msDS-PasswordHistoryLength: 24

msDS-PasswordComplexityEnabled: TRUE

msDS-PasswordReversibleEncryptionEnabled: FALSE

msDS-LockoutObservationWindow: -6000000000

msDS-LockoutDuration: -18000000000

msDS-LockoutThreshold: 3

msDS-PasswordSettingsPrecedence: 10

Note that the raw format for the maximum password age, minimum password age, lockout observation window, and lockout duration is the classic Windows NT time interval “ticks”, which is a negative number representing the number of 100 nanosecond units in the duration. These are 64-bit values which are referred to as Integer8 (eight octets), or LargeInteger values, depending on if you ask a schema person or a developer.

When entering these values in ADSIedit, I’ve seen/heard people suggest that we use the ticks value for the time intervals, however, it is also possible to enter a value of (none), (never), or a duration in d:hh:mm:ss notation – days, hours, minutes, and seconds. A value of 0:00:10:00 represents 10 minutes. There really is no need to resort to ticks unless you prefer to count time that way.

Both ADUC’s Attribute Editor and ADSIedit support entering these values in d:hh:mm:ss notation, which automagically translates to the negative ticks notation required for time intervals.

In another article, we’ll look at the meaning of these settings, then later how to apply them to groups, and finally how to avoid the gory details of managing these in Windows Server 2008 and use PowerShell in Windows Server 2008 R2 for more fun and power.

PowerShell ISE Output Transcription


My past couple of posts have looked at PowerShell ISE and described a few aspects of the Script and Command panes, with a brief mention of the Output pane.

Now I’d like to address some noteworthy aspects of the Output pane.

One of the natural habits I have developed when working with PowerShell is to run Start-Transcript before I get into any new work. The transcription feature has been a part of PowerShell since version 1.0. Having a transcript of the commands I’ve typed as well as the output from the shell can be used in auditing, peer review and training, documentation, and script development. It’s almost hard to imagine using transcripts – the same would be true of history. In fact, if I have forgotten to run Start-Transcript before I get into script development, as often happens with the realization that what the previous few commands have done would be even better in a script, and with prototyping, my quick remedy is to run Start-Transcript and then immediately follow-up with a good dose of Get-History. That way everything I’ve done recently is in the transcript, well at least the commands but not the output.

I panicked when I first found out that the PowerShell ISE console host does not support transcription! If you type Start-Transcript in PowerShell ISE, you get an error to this effect. Then I took a deep breath and it dawned on me: I’m in an integrated scripting environment. It’s not quite the same, but has it’s own form of power.

Consider the following sequence.

<Ctrl>+N    – creates a new script document tab

<Ctrl>+<Shift>+O    – navigates to the Output pane

<Ctrl>+A    – selects all of the commands and output in the Output pane

<Ctrl>+C    – copies the whole Output pane contents

<Ctrl>+I    – navigates to the Script pane

<Ctrl>+V    – pastes the Output pane contents into the Script pane

<Ctrl>+S    – initiates saving the output

Remember: nOacivs (or Oacnvs, etc.) It just rolls off the fingertips after you’ve done it many times. But what does this sequence do? Because the Output pane contains each Command that has been typed during this PowerShell ISE session and the resulting output, it’s quite similar to the transcript output, although not automatic. But this kind of taking some commands and output from the session is up-front and explicit. It’s not as hidden in the background, thereby it’s more clear what needs to be done in separating the wheat from the chaff. You can carefully choose what parts of the recent interactive sequence you want for one or more scripts.

Then, once you’ve culled together parts of scripts in this way, the real fun begins, and PowerShell ISE is there to support you – the debugging of scripts. We’ll come back and revisit PowerShell ISE later to discuss that story.

Interactive Commands in PowerShell ISE


Recently, I wrote a brief introduction to PowerShell ISE – the Integrated Scripting Environment available for PowerShell version 2.0 in Windows 7 and Windows Server 2008 R2. After a brief introduction, we mentioned a few tips of placing and navigating to the Script pane, noting that you can hide/show it by typing <Ctrl>+R.

Beside sporting the tabbed script editor, PowerShell ISE provides a more organized way of running interactive commands than the classic Command Prompt console host window for PowerShell offers. Let’s focus on the Output and Command panes of PowerShell ISE.

If you’re like me, you may have a tendency to type long interactive command or function definitions and code blocks at the command prompt. By default, the shell prompt includes the letters “PS,” a space, the current location, a greater than and a space, for example:

PS C:Windowssystem32>

Once you go deep, into the dark corners of the file system, the registry, Active Directory, or other interesting locations, the path can become really long, perhaps even longer than one line itself. While it’s good to know where you are, does the prompt have to be so prominent? Does it have to get in the way of typing a long command? If you want to use a bigger font, why does the prompt have to get bigger too? It doesn’t. Not anymore.

In the Command pane of the PowerShell ISE window, the prompt is shown at the top edge of the pane on a line by itself. Another greater-than “>” prompt appears on the next line with ample room to type, starting close to the left margin of the window. If you change the font size of the Command pane using the convenient slider on the bottom right corner of the status bar, front anywhere between 8 point and 32 point, the innocent little prompt which includes the path stays nice and modest at its default 12 pt. Note that changing the Command pane font size from the 12 pt. default also changes the Output font size, this is immensely handy for zooming in to read some tiny text, or zooming out to fit more data in the window. What, you don’t want to use your mouse to adjust the slider? No problem, use <Ctrl>+Add (either + or = works) to zoom in and <Ctrl>+Subtract (either – or _ works) to zoom out one point at a time.

Classic editing keystrokes, such as <Ctrl>+C to copy and <Ctrl>+V to paste work nicely in the Command pane. The arrow keys, <Ctrl>+arrows, <Home>, <End>, and other keys behave like they ought. Once you have typed <Enter> to execute a command, the full prompt, the command you’ve typed, and its output don’t clutter up the Command pane, but instead appear together in the Output pane, delimited by a horizontal rule line. This makes reading through a sequence of interactive commands and their results far easier than with the archaic Command Prompt single-pane interface. To switch the cursor to the Output pane, simply type <Ctrl>+<Shift>+O (<Ctrl>+O opens a file), and to get back from either the Output pane or the Script pane to the Command pane, merely type <Ctrl>+D.

This PowerShell ISE is a far, far better thing that we do now, than most Windows shells you have ever done. Actually it depends on what Windows shells you’ve used, yet verily it is nigh undeniable that this is better than the classic Windows Command Prompt.

Ah, but time flows on; come back soon for more on Windows PowerShell ISE.