Comparing PowerShell Switch Parameters with Boolean Parameters

If you’ve ever take a look at the help output (or TechNet documentation) for PowerShell cmdlets, you see that they list several pieces of information about each of the various parameters the cmdlet can use:

  • The parameter name
  • Whether it is a required or optional parameter
  • The .NET variable type the parameter expects
  • A description of the behavior the parameter controls

Let’s focus on two particular types of parameters, the Switch (System.Management.Automation.SwitchParameter) and the Boolean (System.Boolean). While I never really thought about it much before reading a discussion on an email list earlier, these two parameter types seem to be two ways of doing the same thing. Let me give you a practical example from the Exchange 2007 Management Shell: the New-ExchangeCertificate cmdlet. Table 1 lists an excerpt of its parameter list from the current TechNet article:

Table 1: Selected parameters of the New-ExchangeCertificate cmdlet

Parameter Description

GenerateRequest
SwitchParameter)

 

Use this parameter to specify the type of certificate object to create.

By default, this parameter will create a self-signed certificate in the local computer certificate store.

To create a certificate request for a PKI certificate (PKCS #10) in the local request store, set this parameter to $True.

PrivateKeyExportable
(Boolean)

Use this parameter to specify whether the resulting certificate will have an exportable private key.

By default, all certificate requests and certificates created by this cmdlet will not allow the private key to be exported.

You must understand that if you cannot export the private key, the certificate itself cannot be exported and imported.

Set this parameter to $true to allow private key exporting from the resulting certificate.

On quick examination, both parameters control either/or behavior. So why the two different types? The mailing list discussion I referenced earlier pointed out the difference:

Boolean parameters control properties on the objects manipulated by the cmdlets. Switch parameters control behavior of the cmdlets themselves.

So in our example, a digital certificate has a property as part of the certificate that marks whether the associated private key can be exported in the future. That property goes along with the certificate, independent of the management interface or tool used. For that property, then, PowerShell uses the Boolean type for the -PrivateKeyExportable property.

On the other hand, the –GenerateRequest parameter controls the behavior of the cmdlet. With this property specified, the cmdlet creates a certificate request with all of the specified properties. If this parameter isn’t present, the cmdlet creates a self-signed certificate with all of the specified properties. The resulting object (CSR or certificate) has no corresponding sign of what option was chosen – you could just as easily submit that CSR to another tool on the same machine to create a self-signed certificate.

I hope this helps draw the distinction. Granted, it’s one I hadn’t thought much about before today, but now that I have, it’s nice to know that there’s yet another sign of intelligence and forethought in the PowerShell architecture.

A certificate roundup

Certificates are one of the biggest issues I keep hearing about with Exchange and OCS, and apparently I’m not the only one. Fellow MVP Michael B. Smith has recently posted two blog articles on certs: how to use SAN certificates with ISA 2006 and other certificate limitations. However, he’s got a couple of points on the second article that I’m confused about:

  • According to this announcement on the Windows Mobile team blog, Windows Mobile 6.0 and up do in fact support wildcard certificates.
  • The first point he makes is also head-scratcher, because I’ve also heard this was an issue, but I’d also recently heard of a workaround for it:
    1. In Outlook, go to the properties for your Exchange account (Tools, Account Settings, select your Exchange account and click Change) and click More Settings.
    2. On the Connection tab, click Exchange Proxy Settings.
    3. Look for the field Only connect to proxy servers that have this principal name in their certificate and make sure it’s checked (you may need to check the Connect using SSL only checkbox first).
    4. The value in this field should normally be set to msstd:server.external.fqdn, the FQDN the server is known as from the outside and that is the subject name of the certificate. So if my certificate was issued for 3Sharp, it would be msstd:mail.3sharp.com. To use this with a wildcard certificate issued to *.3sharp.com, this value would need to be set to msstd:*.3sharp.com.

      Let’s try a diagram to make the point:
       image

I’m doing more checking, trying to figure out what the deal is here; in the meantime, if you’ve got operational experience with either of these issues, please let me know.

At any rate, there’s some more interesting factoids on certificates I’ve picked up:

  • If you want to use a certificate with the Exchange 2007 UM role, you need to have a certificate on the machine whose subject name matches the server’s AD/DNS FQDN. It seems that you can’t enable a certificate for the UM service using the Enable-ExchangeCertificate cmdlet if this does not match. Note that you can do this for other services, such as those hosted by the CAS role; the cmdlet performs different name checks on the certificate based on the services (SMTP, POP3, IMAP, HTTP, and UM) that you are enabling.
  • I’ve said it before, but it needs to be repeated: if you’re not using the default self-signed certificate, simply use the Enable-ExchangeCertificate cmdlet to move all services to one or more additional certificates. Do not delete the default certificate; although in most cases Exchange will simply recreate it when the appropriate service is restarted, you can cause subtle errors that will take a while to figure out.
  • Learn more about certificate usage in Exchange in Creating a Certificate or Certificate Request for TLS.
  • And learn more about the Enable-ExchangeCertificate cmdlet.

More later!

Sweet PowerShell lovin’…for free!

And yes, that’s “free as in beer,” not “free as in what some people think all information wants to be.”[1]

Frank Koch and Marcel Trümpy of Microsoft (in Switzerland) have created not one, but two Windows PowerShell ebooks, and you can get them both for free:

  • A Windows PowerShell course book with associated demo files and examples.
  • A Windows PowerShell server administration book with associated demo files and examples.

Get them both in one easy download either in English or German. The downloads are from Microsoft and no registration is required, according to the blog posting.

[1] If you believe all information wants to be free, I challenge you to put your money where your mouth is and post your Social Security number (if you live in the USA; equivalent if you don’t), birthdate, address, personal phone number, and bank account information here in my comments. After all, that’s all information — and it wants to be free!

Liveblogging the Unified Communications Voice Ignite conference, day 3

Good morning! Back for day 3. (You can see my day 2 notes here.)

09:13: Back when I first started doing OCS, the vision included “hybrid“ gateway devices which included the Mediation Server role functionality in the gateway. Well, they exist now — partners have been busy! (source http://technet.microsoft.com/en-us/office/bb735838.aspx)

10:25: User provisioning can be fun. When provisioning users, you need to populate the msRTCSIP-line attribute with their phone number in E.164 format. OCS doesn’t look at the regular Active Directory phone attributes. You can populate the msRTCSIP-line attribute from the AD attribute, but you need to make sure that you normalize the numbers to E.164 format first. Best case: normalize your AD phone numbers! (source http://technet.microsoft.com/en-us/library/bb870372.aspx)

10:47: WMI is the preferred interface for writing user provisioning scripts — this allows you to do it in the language of your choice, including (yay!) PowerShell (via PowerShell’s WMI provider). The Resource Kit gives you lots of useful scripts (yes, including PowerShell) and samples as a starting point. (source http://www.microsoft.com/downloads/details.aspx?FamilyID=b9bf4f71-fb0b-4de9-962f-c56b70a8aecd&displaylang=en and http://blogs.technet.com/jamesone/archive/2007/08/19/powershell-and-paradigms-of-vb.aspx)

10:51: Mmm. These brownie-walnut-tart thingies are TASTY.

11:04: Kevin’s all hooked up for pictures, so you can see the brownie-walnut-tart thingies for yourself.

12:22: About to jump into more tasty crunchy labs, but before I do, one word of advice — bone up on regular expressions. (source http://technet.microsoft.com/en-us/library/bb803637.aspx, http://www.microsoft.com/downloads/details.aspx?FamilyID=b9bf4f71-fb0b-4de9-962f-c56b70a8aecd&displaylang=en, and http://www.microsoft.com/technet/technetmag/issues/2008/02/OCSTelephony/default.aspx)

14:28: RTP (Realtime Transport Protocol, not RealTime Protocol as many people think) is cool! There’s some clever engineering going on here, although the comparitive size of the header and the payload is pretty skewed, especially once you get all the UDP, IP, and physical link overhead in there – remember the overhead from 09:38 in the day 2 notes? That’s where it comes from. (source http://tools.ietf.org/html/rfc3550, http://forums.microsoft.com/unifiedcommunications/ShowPost.aspx?PostID=2697675&SiteID=57)

15:35: Even though a lot of the OCS conceptual diagrams show the three Edge server roles on separate machines, it is not supported to install these three roles on separate machines. You can deploy all three roles on a single machine OR you can have A/V Edge on one server and Access Edge + Web Conferencing Edge on another server. Each of these servers can also be load balanced server configurations. You can’t load balance a consolidated single server (all three Edge roles) configuration. I’m guilty of getting this one wrong, so if you saw me speak at one of the UC roadshows last fall, make note! (source http://technet.microsoft.com/en-us/library/bb663789.aspx)

15:44: Note that while a reverse proxy (such as ISA) is not a required part of the whole remote access deployment, by not using it you will lose functionality from external clients that aren’t using a VPN connection: you won’t be able to expand AD groups and get their memberships, you won’t be able to download the address book information (which contains all of that lovely normalized phone number information you went to such pains to configure), and you won’t be able to download meeting content in Live Meeting conferences. By reverse proxy, think something like ISA 2006 (which is recommended) or other equivalent applications or appliances. (source http://technet.microsoft.com/en-us/library/bb803627.aspx)

15:51: Contrary to popular belief, the Access Edge server does not perform authentication of incoming remote connections. They do provide validation of incoming SIP requests (filtering out requests to invalid SIP URIs, etc.), but they don’t authenticate. Authenticaton happens either by the OCS Standard Edition server, the OCS Enterprise Edition Front-End pool, or the optional (but highly recommended) Director role. Director roles can be load balanced for greater reliability. (source http://technet.microsoft.com/en-us/library/bb663752.aspx)

17:36: Byron Spurlock has a fantastic blog on OCS at http://blogs.msdn.com/byrons/default.aspx — the only flaw is that Byron needs to update more frequently! Great stuff!

17:42: Want to find the latest and greatest list of UC-compatible certificates? Look no further than KB 929395. However, be aware that this KB doesn’t seem to have been updated recently, and it doesn’t help you figure out which certificates will automatically be trusted by Windows Mobile devices or Office Communicator Phone Edition devices. The key sentence is If the OCS 2007 servers use public certificates they will most like be automatically trusted by the device, since it contains the same list of trusted CA’s as Windows CE.

Continue on to my Day 4 notes.

Post-Connections report

Vegas was great again, this year; the hotel was as lovely as ever, but the overlap with the Latin Grammys sure did some interesting things to the elevators. Mandalay Bay felt full this year! On the other hand, the beach remodel was excellent; the wave pool and the Lazy River pool were both hits with my family. As is my wont, I’m making my session slide decks available for download.

  • EXC16: Advanced Exchange Protection using Data Protection Manager
    Backing up and restoring Exchange servers is an essential part of keeping your messaging infrastructure up and running, even when you’re running an advanced clustering configuration. Why should you consider using the new version of Microsoft System Center Data Protection Manager (“v2“) to protect your Exchange server clusters? Is it any harder than backing up standalone servers? This session covers protecting Exchange 2003 and 2007 servers clustered configurations, including the new Exchange 2007 replication options.

    I thought this session went pretty well; there was a Microsoft session on Tuesday morning that looked like it was going to cover the exact same material, but the overlap was both smaller and shallower than I expected. I got a lot of good questions from this session which I’ll be answering in the next couple of days; I really hope that I was able to convey my own excitement about DPM and how it will make a great partner for protecting Exchange.

  • EXC17: Exchange Management Shell Annoyances
    The Exchange 2007 Management Shell makes full use of the exciting new Windows PowerShell technology. It’s a great command-line management experience, but it’s still not perfect. You may have already been tripped up by annoyances and complications in what seem to be obvious tasks or you may just want to know what dangers lurk beneath the surface. This session will show you some common pitfalls and problems and give you the knowledge to successfully navigate them.

    This session suffered from the inevitable technical glitches; my Exchange virtual environment died an hour or two before the session, so I ended up having to run it from a stock Windows PowerShell session. Luckily, I was able to cover most of the territory from there and even add a couple of things or two. Not having the Get-Help and cmdlet completion information for EMS, though, just sucked; my apologies.

  • EXC18: Getting Run Over by Exchange 2007
    Common knowledge says that upgrading to Exchange 2007 isn’t nearly as hard as the upgrade from Exchange 5.5. That’s not to say that it doesn’t present its own set of challenges—and if you’re caught by them, it will still feel like getting run over by a truck. This session will present some of the common gotchas and how to avoid them. Be at the head of the upgrade parade, not caught in the wheels.

    Wow. This was a great session; standing room only and a lot of good feedback and questions. This is clearly a topic of concern to people — if you have any other upgrade gotchas, let me know!

It’s a release!

For those of you who have been waiting for that sweet, sweet DPM 2007 goodness…wait no more. It’s gone RTM. DPM 2007 is an amazing product, so amazing that somebody and his cow-orker are writing a book about it. (Yes, Ryan and I have been pretty busy on this thing; in fact, I get to work on edits to a couple more chapters tonight after I leave work and Ryan is busy rocking the house with some phat lab tracks for your testing and learning pleasure.)

Of course, my absolutely favorite features of DPM 2007 are:

  • DPM makes it easy it makes protecting and restoring Exchange data. Imagine being able to restore an individual mailbox without having to do brick-level MAPI backups! You can do it with DPM.
  • In fact, DPM synchronizes your databases and transaction logs, so you can restore your data to any specific recovery point.
  • DPM 2007 takes a page from the Exchange 2007 playbook with the DPM Management Shell, based on Windows PowerShell. It’s not quite as pervasive as the EMS, but it’s a damned good start.

But don’t take my word for it — download the evaluation software and start playing with it.

Testing your new Exchange 2007 Send connector

Updated 1401 PDT: added the diagram.

A recent post on a mailing list I frequent gives me today’s blog post.

So you’ve got an Exchange 2000/2003 organization and you’ve decided that you want to upgrade to Exchange 2007. You’ve done all the research and planning and you’ve gotten as far as installing the first HT server (CF-EX01) into your organization:

  • We’ll assume that your organization already has an SMTP connector named Legacy SMTP to handle all outbound mail for the SMTP:* address space.
  • Since this is the first Exchange 2007 server, Exchange 2007 Setup has created a new Exchange 2007-only administrative group and a new Exchange 2007-only routing group.
  • It’s also created a bi-direction Routing Group Connector between the HT server and the Exchange 2003 bridgehead (CF-LE01) you specified as your LegacyRoutingServer.

Let’s take a look at things from EMS:

As we expect, we see the pair of RGCs, each with a cost of 1, and our existing SMTP connector, also with a cost of 1. Right now, outbound message flow is easy: anything in the org only has one outbound gateway.

 
One of the first things you might want to do is get all inbound and outbound mail flowing through your new Exchange 2007 HT server. Inbound is easy: we simply change the configuration on our gateway mail machine or firewall server, or change our MX records, appropriately. For outbound, though, we want to create a new Exchange 2007 Send connector and test it before we actually entrust live email to it. Those of you with large Exchange organizations already know how to do this: manipulate your connector costs. If you’re in a smaller organization that only had one routing group, though, this may be a new concept. Don’t worry, it’s pretty easy.

The goal is to create two outbound routes for the SMTP:* address space, one for the Exchange 2003 side of the organization and one for the Exchange 2007 side. The Legacy SMTP connector already gives us the former and we’ll create the latter in a moment. We need to ensure that the costs of all related connectors are set so that:

  • The combined cost of the Legacy SMTP connector, the RGC, and any other connectors in between is greater than the cost of the new Exchange 2007 Send connector from the Exchange 2007 routing group.
  • Likewise, the combined cost of the new Exchange 2007 Send connector and the RGCis greater than the cost of the Legacy SMTP connector from the Exchange 2003 routing group(s).

To meet these goals, depending on how your organization is configured, you MAY need to mess with the default costs. In our sample organization where we have just two routing groups and we’ve used the default costs for all connectors, this is precisely how it all works out by default. First, though, let’s go ahead and create the new Exchange 2007 Send connector:

Yup — two SMTP connectors, each with the SMTP:* address space and a cost of 1. Here’s a quick diagram:

image

Now, let me show you how the routing currently works:

  1. From the Exchange 2007 routing group, we look for our lowest cost to the SMTP:* address space. We see two connectors that match.
    • Our total cost to Legacy SMTP is 2, since its bridgehead is homed in the Exchange 2003 routing group. Cost 1 to navigate the RGC plus cost 1 for the connector.
    • Our total cost to New SMTP is 1, since its bridgehead is homed in the same routing group we’re in. This is our choice.
  2. From the Exchange 2003 routing group, we look for our lowest cost to the SMTP:* address space. Again, wee see the same two matching connectors.
    • Our total cost to New SMTP is 2, since its bridgehead is homed in the Exchange 2007 routing group. Cost 1 to navigate the RGC plus cost 1 for the connector.
    • Our total cost to Legacy SMTP is 1, since its bridgehead is homed in the same routing group we’re in. This is our choice.

Now, we can begin our testing. We’ve got several ways to do this:

  • Add an Exchange 2007 mailbox server, create a test account, create an Outlook profile, and go to town.
  • Add a test mailbox to an existing Exchange 2003 mailbox server and set it up for IMAP/POP3 access. Use Outlook Express or Outlook to set up the mail account, and specify our Exchange 2007 Hub Transport server as the SMTP server.
  • Telnet to port 25 of the Hub Transport server and submit messages manually. You might need to allow anonymous connections on the Default Receive connector if you do this, unless you can do NTLM and Base64 encoding in your head. (If you can, you scare me.)

Still with me? Whew! One last piece: we need to change the route costs when we’re all done with our testing and are ready to flip the switch. Sure, you can do it from the GUI, but where’s the fun in that? Simply use EMS to modify the address space on the Legacy SMTP connector to set its cost higher than the combined total of the RGC + New SMTP connector:

That, by the way, is how you update a cost: modify the AddressSpaces parameter on the connector. If you have multiple address spaces, this gets a little bit more complicated; you have to supply all the values instead of just one. We’ll talk about techniques to do this later…perhaps in one of my upcoming sessions at Exchange Connections Fall 2007 in Las Vegas!