February 2008 - Posts

Exchange 2007 has a leap year bug.

No more information than that, really; but under certain configurations, Exchange is generating:

Event ID: 2451

Source: MSExchange ADAccess

Type: Warning


"Process powershell.exe (EMS) (PID=1250). Contacting server fqdn.of.mailbox.server.example.com for RUS RPC service returned RPCException 'Error 6ba from FilterAttributes". Server will not be used for RUS RPC.

and not processing any user creations or recipient updates.

Let's just hope it disappears at midnight tonight...

Posted by michael | with no comments
Filed under:

In March of 2006, I authored this blog post, Finding Services Using non-System Accounts, with the script being written in VBscript.

Two years later, most of my environment is now in PowerShell. So, I've decided to update that post with the PowerShell equivalent.

The VBscript version of the utility was 155 lines long. The PowerShell version is 89 lines long, and the PowerShell version corrects a couple of bugs that were present in the VBscript version (for example, if a service's startup account was specified with an administrator account specified as a UPN, the VBscript would not detect the account as an administrator account).

The PowerShell version was created by doing almost a line-for-line translation of the VBscript utility; only a few things are PowerShell optimized. For example, the "real PowerShell" way to do the checkExclusions() function would be for $arrExclude to be a hash array (associative array). Once that change is made, there is no need for the checkExclusions() function at all - you simply index the array with $account to tell whether or not the account is a member of the array. That would save another 15 lines of code right there. But I didn't know that when I translated the utility. :-)

On the other hand, instead of reading the file line by line, I did optimize that loop by using the PowerShell get-content cmdlet.

The "listofcomputers.txt" file remains in the same format. A small example look like this:

# comment lines

Where any line beginning with a '#' is a comment. A '.' indicates the current computer. All other lines contain a computer name. It may be a short-name or a long (fully-qualified) name. Output (in my environment) for the above input looks like this:

PS C:\Scripts> ./check-services

Checking computer .
Account administrator@essential.local; Service Themes; Caption Themes
Account .\administrator; Service WmiApSrv; Caption WMI Performance Adapter

Checking computer win2003-dc

Checking computer win2008-exch
Get-WmiObject : The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
At C:\Scripts\Check-Services.ps1:30 char:17
+     $results = gwmi  <<<< win32_service -computer $strComputer -property name, startname, caption
Error occurred

Checking computer win2003-scom
Get-WmiObject : The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
At C:\Scripts\Check-Services.ps1:30 char:17
+     $results = gwmi  <<<< win32_service -computer $strComputer -property name, startname, caption
Error occurred

Processing complete.
Total computers processed: . . 4
Total Administrator services:  2
Total special services:  . . . 2
Total comment lines: . . . . . 3
Total errors:  . . . . . . . . 2
PS C:\Scripts> 

Note the detailed error messages. PowerShell gives you those "for free" by default. In this case, Win2008-Exch has had the SCW (Security Configuration Wizard) run on it to lock it down - it doesn't allow remote management. I need to fix that. :-) Also in this case, Win2003-SCOM is turned off. The errors are the same because WMI can't know the reason that a computer does not respond.

So, without further ado, here is the script:

Param ([string]$strFile = "listofcomputers.txt")

$arrExclude = "NT AUTHORITY\LocalService",
      "NT AUTHORITY\NetworkService"

$script:iAdmin = $script:iTot = $script:iCount = $script:iError = 0

function checkExclusions([string]$strval)
	foreach ($val in $arrExclude)
		if ($val.ToLower() -eq $strval)
			return $true
	return $false

function checkServicesOnComputer([string]$strComputer)
	$iExcluded = $iIncluded = 0
	" "; "Checking computer $strComputer" 

	trap { "Error occurred"; $script:iError++; continue; }

	$results = gwmi win32_service -computer $strComputer -property name, startname, caption

	foreach ($result in $results)
		$account = $result.StartName.ToLower()
		if (checkExclusions $account)
			$adminR = "\administrator";  ## admin-from-the-right
			if (($account.Length -ge $adminR.Length) -and
			    ($account.SubString($account.Length - $adminR.Length) -eq $adminR))
			$adminL = "administrator@";  ## admin-from-the-left
			if (($account.Length -ge $adminL.Length) -and
			    ($account.SubString(0, $adminL.Length) -eq $adminL))
			"Account $account; Service " + $result.Name + "; Caption " + $result.Caption

	$script:iTot += $iIncluded;

function doProcess([string]$filename)
	$computers = get-content $filename
	foreach ($computer in $computers)
		if ($computer.SubString(0, 1) -eq "#")
			checkServicesOnComputer $computer;

	# Main

	doProcess $strFile

	" "
	"Processing complete."
	"Total computers processed: . . $script:iCount"
	"Total Administrator services:  $script:iAdmin"
	"Total special services:  . . . $script:iTot"
	"Total comment lines: . . . . . $script:iComment"
	"Total errors:  . . . . . . . . $script:iError"

Until next time...

I hope you've enjoyed this posting. If there are topics you would like me to cover, please send me an e-mail or leave me a message in the forums.


Recently, the question was asked on one of the mailing lists I frequent: why does Exchange Server 2007 make me create all my new distribution groups as universal groups?

The answer is just a little bit convoluted. And it really only applies to so-called "enterprise" customers - those with more than one or two domains in their Active Directory forest, even though it can effect even SBS (Small Business Server) customers.

In earlier releases of Exchange Server (Exchange 2000 and Exchange 2003), distribution groups could have any of the valid group scopes (domain local, global, universal).

If you want a full explanation of what those scopes mean, see KB 231273.

However, the big thing to know is that domain local groups can only have their membership evaluated by the domain controllers in the domain where they are created (or by a global catalog server for that domain). So if you create a distribution group with domain local scope, or you have a mail-enabled security group with domain local scope, you've got a problem.

Still don't see why? I told you it was convoluted. Surprise

Well, that group is going to be in the global address list. This means that e-mail can be sent to that group from anywhere in the enterprise. Let's say that the group is created in Domain-A and consists of users who have their mailboxes in that domain and are hosted on an Exchange server in Domain-A.

Now, a user in Domain-B picks the address for that group out of the global address list and sends it off to her local Exchange server, which is also in Domain-B.

Her local Exchange server cannot expand the group! And therefore Exchange will return the message to her with a non-delivery report.

That is definitely not expected behavior.

How do you get around it? Well, you can put a global catalog server for Domain-A in the Active Directory site where the Exchange server for Domain-B sits. That can get expensive, both in terms of hardware and in other resources. You can put your Exchange servers in a separate resource forest and run something like MIIS/IIFP to keep all your domains and forests in sync in terms of users and passwords and the like (which can also be expensive in terms of various resources).

Or - you can make the group a universal group. Sounds much simpler, doesn't it? Smile

What are the downsides?

Well, you can't have a universal group until you are in at least Windows 2000 native mode (note: this is not the Exchange mode I am talking about, this is the Active Directory mode). Some large customers can't make that change. Believe it or not, there are still thousands of NT 4.0 servers in corporate networks all over the world.

Also, if you can't go to at least Windows 2003 interim domain functional level, then you can't use an Active Directory feature called LVR - Linked Value Replication with your Active Directory universal groups. Without LVR, when you replicate a group's membership, you replicate the ENTIRE MEMBERSHIP every time. So if a group has hundreds or thousands of members, this can seriously increase your replication traffic - since universal groups have their entire membership replicated to ALL global catalogs in the enterprise.

And finally, you can't go to Windows 2003 interim, or Windows 2003 native, as long as you have Windows 2000 domain controllers in your forest.


If you want more information about domain and forest functional levels in Windows Server, what they affect and why you may or may not can change them, see KB 322692. However, if those changes impact you, you probably already know about them.

So, to fix the original problem (where Exchange could sometimes not expand a group to send e-mail to it), the Exchange developers had a couple of choices. They were:

1]  Make a big change to how Exchange expands groups and attempt to contact source-domain group catalogs (which may not be available!) to do that expansion, including all the overhead and delay introduced by that.


2]  Make mail-enabled groups be universal groups.

Well, the answer seems obvious to me. And apparently was obvious to the Exchange developers!

So, to get Exchange groups acting the way you expect, you need to be at Windows Server 2003 Domain Functional Level (DFL) and Forest Functional Level (FFL) and have all your mail-enabled groups be universal groups.

If you are a small company this is probably easy to do. If you are a large company, I encourage you to examine using PowerShell to automate the process. Smile

Until next time...

Thanks for reading! I hope you found this interesting. If you have topics that you would like to see me cover, send me an e-mail or leave a message in the forums.

MS08-03, an "important" February security bulletin designed to prevent Denial of Service attacks against Active Directory and ADAM (Active Directory Application Mode) apparently has some issues with Exchange 2007 in larger organizations.

I first heard of this from Pete Kretche, a Systems Administrator for the University of Wisconsin Green Bay in an Exchange mailing list posting. He said:

Anyone noticed this on their Exchange 2007 server(s)?


Active Directory operation failed for <DC FQDN>. This error have been caused by user input or by the Active Directory server being unavailable.  Please retry at a later time.  Additional information: The directory service encountered an unknown failure.

Active Directory response: 000020EF: SvcErr: DSID-020A0EA3, problem 5005 (UNALBE_TO_PROCEED), data 87.

It was running command ‘get-recipient –ResultSize ‘10000’ –SortBy ‘DisplayName’ –RecipientType ‘Usermailbox”.


If so, check your DC’s for the February MS08-003 security patch KB943484.  This patch limits the LDAP query capability to prevent DoS attacks.  Apparently MS forgot to test Exchange 2007 against this patch.  The patch is gone back in for some re-work and will be made available again sometime in March with the ability to change a reg value for the number of objects returned.  I’m in no way advocating removing KB943484, just sharing information to keep fellow admins from pulling out their hair like I did today.

I e-mailed a Microsoft contact and verified that this is an ongoing issue and is currently being tracked by Microsoft Product Support Services.

Based on the error message and my knowledge of Active Directory limits, I would surmise that this is not going to happen in small or medium size shops. That is, shops who have less than 1,000 recipients.

You bigger guys might want to check this out...

Edit - later on 2008-02-26:

Pete was kind enough to forward the errors that occur. Please see the images below.

Note that the blank space on the first line of both images would contain the fully-qualified-domain-name of the domain controller that the Exchange Management Console was attached to.

Exchange Error from Exchange Management Console #1


Active Directory Error from Exchange Management Console #2


SSL stands for Secure Sockets Layer. As the Secure part of the name implies, the purpose behind SSL is to secure communications between a client browser (such as Internet Explorer or FireFox) and the server service with which the browser is communicating (which may be web browsing, IMAP, POP-3, etc.).

SSL works by encrypting data - that is, applying a mathematical formula to it on one end, sending it to the destination, which knows how to apply a reverse mathematical formula to the encrypted data in order to get the original data back (this is known as decryption).

SSL can take a lot of computer power, if the website is encrypting graphics and images, as well as text. Most SSL websites and/or subsites are "light" - they have little graphics and/or images, in order to minimize this overhead.

SSL is often used for financial transactions, login transactions, and any other type of communication that is desired to be very secure. For example, installing the OWA Admin tool on your Exchange Server also installs a self-signed (that is, non-third party) SSL certificate on your Exchange Server.

However, self-signed certificates have a problem - each time they are used, they pop-up a warning message indicating to the user that a non-standard certificate is being used. Or, they require the end-user to load the certificate into a special place on their computer, to actually indicate that the certificate is safe.

To avoid this, every operating system pre-loads authority information for a certain number of companies that issue certificates. If you acquire your certificate from one of those companies, then that warning dialog never appears.

In North America, probably the three most common certification authorities (that is, companies from whom you can buy SSL certificates) are VeriSign, Thawte (which is owned by VeriSign), and Entrust. Certificates issued by these companies are recognized by probably every internet browser in the world.

In the email world, SSL certificates are often used to protect web mail communications, including (perhaps most significantly) the sign in process. This ensures that passwords for users are not transferred over the Internet in the clear (where they could easily be discovered). SSL may also be used to encrypt the various email protocols, when communicating with a client that knows how to do the same. There are defined and Exchange supported mechanisms for using SSL with SMTP, with POP, and with IMAP along with the normal HTTP (World Wide Web). An evolutionary improvement to using SSL with SMTP is called TLS - Transport Layer Security. TLS also requires an SSL certificate and is supported by Exchange Server.

Whether using SSL certificates is worthwhile or not is beyond the scope of this article, although it should be noted that using SSL certificates with OWA, IMAP, and POP3 is considered a best practice. There are many fine books that discuss the security implications of encryption and decryption and not using the technologies. The first step along the process to secure communications is to obtain the SSL certificate. The first step to obtaining an SSL certificate is to generate a Certificate Signing Request (CSR).

Windows Vista, Windows XP, and Windows Server 2003 provide a number of different mechanisms for maintaining the certificate store on a computer, each targeted for different needs. The first, the Certificates MMC, provides a simple mechanism for viewing, interrogating, and deleting existing certificates on a computer.  However, its interface for requesting certificates is poor.

Secondly, if a Certification Authority is installed on a server, it has an administration interface available at http://<servername>/certsrv.

For many years, the mechanism that was most interesting for for Exchange was the "Create a New Certificate" wizard which is present in the Internet Information Services Manager (ISM). This is the interface you use in Exchange 2000 Server and Exchange Server 2003 to generate a certificate signing request.

In Exchange Server 2007, you will use the "New Certificate" wizard (available from an Exchange server object in the Exchange Management Console), or the "new-exchangecertificate" cmdlet in the Exchange Management Shell.

Until next time...

As always, if there are topics you would like for me to cover, please e-mail me or leave a message in the forums.

Posted by michael | with no comments

Not generally in keeping with the things I post, but I just had to share this video I just watched:

How To Behave On An Internet Forum

I still have tears running from my eyes.

Posted by michael | with no comments

Originally published in January of 2005, my blog post Exchange Server 2003 and Domain Controllers - A Summary has been the most searched-out article on my blog.

While, with the release of Exchange Server 2007, the post is beginning to show it's age, the information contained in the article still applies to Exchange Server 2007 - just some links need to be updated.

One item not covered in that post is the security aspect of installing Exchange on a DC. An Exchange Administrator needs to be a local administrator of the Exchange Server she is responsible for administering. That's simply the way permissions are done within Exchange. (This does not apply to viewing information, only to modifying it.)

I recently came across a document that suggested that when installing Exchange on a DC, the proper way to assign permissions to an Exchange Administrator was to add that user to the BUILTIN\Administrators group on the DC.

Don't do it.

A member of LOCAL\Administrators is a far cry from a BUILTIN\Administrators, and here are the two primary reasons why:

One - BUILTIN\Administrators is not stored locally to a single DC - its membership is in the Active Directory, in the CN=Builtin,DC=domain,DC=com container. The contents of this container are replicated to all domain controllers. Therefore, adding a user to a member of this group on one DC makes them a member of the group on all DCs. (A member server has a local accounts database called a SAM that is not visible to the domain.)

Two - Since BUILTIN\Administrators gives local Administrator permissions to its members - they can do anything on any DC in the domain. Anything. Making themselves a Domain Administrator is a trivial exercise.

A final note of caution: it is now widely recognized that forests are the security boundaries in Active Directory, not domains (regardless of what the original Windows 2000 Server A/D documentation said). Domains are simply administrative boundaries. As a corollary to item two above, once a person is a domain administrator, it is fairly easy to become an enterprise administrator.

Now, if you are a small shop with one or a handful of servers; this may not concern you. Your Exchange Administrators are probably Domain Administrators already.

But if you are larger - don't do it. The recommendations to do so just give you a false sense of security.

This is just another good reason to NOT install Exchange on a DC.

Until next time...

As always, if there are posts you would like to see, please let me know! Drop me a line or make a comment on the blog. Thanks for reading.

As I reported here, I got all my applications moved over (except for MOA 2007 and since then, MOA 2008).

We determined that the MOA installation issue revolves around the aborted SQL Express 2005 installation that MOA 2007 attempted to do. If you make this move, I recommend that you install SQL x64 BEFORE you attempt to install MOA, use the Advanced installation option, and point MOA to your pre-installed copy.

If you do this, you should be fine.

As you probably know (I blogged about it here), Windows Vista service pack 1 recently released. I installed it and I've been very happy with it.

Today, however, I received my first EVER BSOD (Blue Screen of Death) from Vista. This was the BSOD:

Problem signature:
  Problem Event Name: BlueScreen
  OS Version: 6.0.6001.
  Locale ID: 1033

Additional information about the problem:
  BCCode: da
  BCP1: 0000000000000103
  BCP2: FFFFFA600A722000
  BCP3: 000000005F786D56
  BCP4: 000000000000000A
  OS Version: 6_0_6001
  Service Pack: 1_0
  Product: 256_1

Files that help describe the problem:

Read our privacy statement:

I was shocked, to say the least. Googling around for this BSOD 0x000000DA (SYSTEM_PTE_MISUSE) indicates that in earlier versions of the Operating System, this could happen when you have TrackPTEs turned on, and a driver dereferenced a bad memory block. Well, Vista doesn't have that registry value.

And none of the 3 files referenced in the BSOD actually exist! (They may have been removed when Vista reported the problem to Microsoft - I'm not sure about that.)

I'm guessing this has something to do with having more than 3.5 GB of RAM with an nVIDIA graphics card, based also on Google searches. Since my install is fresh, I'm pretty sure I'm running the latest nVIDIA drivers; but I'm going through the 40.5 MB download again, just in case a bit was corrupt or something (I have no clue).

Posted by michael | 3 comment(s)
Filed under: ,

So, apparently I missed the announcement.

The Exchange Team hosts, along with the Exchange TechCenter and the Exchange Team Blog, a wiki! It's called ExchangeNinjas and has some pretty decent stuff on it. Check it out.

Posted by michael | with no comments
Filed under:

I've seen this a couple of times now - so a blog post will make the solution searchable via Google for other folks to find. ;-)

I've requested that a check for this be added to ExBPA, we'll see if that happens. The error is:

Exchange is unable to mount the database that you specified. Specified database <GUID>; Error code: MapiExceptionAmbiguousAlias: Unable to mount database. (hr=0x80004005, ec=2202)

This occurs during when trying to mount a mailbox database on a new Exchange 2007 server.

This happens in a migration environment when an account having Exchange administrative privileges has a sAMAccountName but no userPrincipalname. More specifically, a specific user was delegated Exchange rights in a pre-Exchange Server 2007 environment, and had a "pre-Windows 2000 logon name" specified in ADU&C, but not a "User logon name".

There appears to be a similar issue in Exchange Server 2003, introduced by a post-SP2 hotfix. KB 932599 and KB 930241 discuss that problem.

A fairly simple solution appears to be to use the Exchange Server 2003 administration console (ESM) to determine all of the accounts that have been delegated Exchange administrative privileges and ensure that they all have userPrincipalNames ("User logon names" in ADU&C).

Posted by michael | with no comments

In this article I reported on the fact (then) that single level domains were not supported in Exchange Server 2007 sp1.

Microsoft, as of today (February 15, 2008) has changed their position on single-level domains and Exchange Server 2007. This is the Microsoft Exchange Team blog post on the topic.

It's worthwhile to note a couple of things:

1) They'll support it - but will not change things that don't work with it
2) It will NOT be supported in the next version of Exchange (code-named E14)
3) A domain rename tool is NOT planned for Exchange 2007
4) Outlook Anywhere/Autodiscover will not work properly in a SLD

Until next time...

As always, if there are items you would like me to talk about, please drop me a line and let me know!

I've been working with an increasing number of small business clients the last few months, as I work to grow my personal consulting business; along with a greater variety of enterprise clients.

A very common problem - servers don't reboot.

In the enterprise environments a few months ago, I was seeing common reboot problems revolving around the Server 2003 Scalable Networking Pack (which I documented in this blog entry).

In the enterprise environments, disabling the TCP Chimney usually seems to have fixed the server not rebooting issue. Apply patches, and on your way you go.

However, something else is going on with SBS 2003. Even with TCP Chimney disabled, many folks (including me!) are seeing that SBS servers are not rebooting when instructed to do so.

Interestingly, the server continues to work - you simply cannot RDP to them, and they don't reboot as instructed.

I have discovered (yeah, I know, it's pretty obvious if you know that the shutdown command exists!) that if you have access to another server or to a "modern" workstation (XP or Vista) that you can make the server reboot via the

	shutdown -r -f -m \\servername

command. So, if you are applying patches remotely, make sure that you have a way to access another server or desktop in that environment, in case you get bitten with this "bug".

Microsoft is aware of the problem, but I don't have any official word on it.

Writing on this same problem, Susan Bradley, an SBS MVP, recently reminded people that Dell and HP servers often ship with remote controller cards, called DRAC (Dell Remote Access Card) and ILO (HP Integrated Lights Out) that can enable you to do a remote reboot of your server. I would add that you need to configure these before-hand for them to do you any good!

Until next time...

As always, I hope this article has been of use to you. If there are topics you would be interesting in seeing me cover, please drop me a line and let me know!

Posted by michael | 4 comment(s)
Filed under: ,

On January 31, in this post I reported that I had loaded 64-bit Vista on my laptop and that things were going well.

As I reported then, I expected it to take several weeks to re-install all my applications, but that my main applications were already running and I didn't anticipate any issues.

As of today, I've got everything migrated. I was able to find a 64-bit version (or the 32-bit version was 64-bit compatible) for EVERY SINGLE application. Except one.

Up front, I will admit, I took the opportunity to do just a tiny bit of changing. One single program. Stick out tongue I was using a laptop-vendor supplied DVD-Writer program, and I went to DeepBurner instead. Which I like more than the vendor supplied utility anyway!

So, which application is now sitting in my "Hall of Infamy"?

Microsoft Office Accounting Professional 2007. And, believe it or not, the brand new version of the same program: Microsoft Office Accounting Professional 2008.

Neither one of these programs will install on Vista x64.

I am irritated. To say the least.

I had to create a 32-bit Virtual Machine JUST to run my invoicing/accounting application. From Microsoft. How absurd.

I've posted an inquiry to the relevant "discussion forum" (Usenet newsgroup microsoft.public.sba.general). You can keep up with the thread here, if you are interested.

Posted by michael | 1 comment(s)
Filed under: , ,

I first got really interested in Exchange Server when I started working on hosting the product for multiple companies (while using only a single server environment). In fact, I started this blog to talk mainly about hosted Exchange. My interests have expanded and I enjoy working with all of Exchange now.

In the "old days", getting information about putting together a platform for provisioning hosted Exchange was really difficult. The information that was available was scattered and a lot of it depended on "who you know" as to whether you could get enough technical information to resolve a problem.

By the time Exchange 2003 was released, the information was pretty widely available in various technet, knowledge base and newsgroup postings (google to the rescue!). Then, shortly before Exchange 2007 was released, many of those sources began to disappear. The reason?

Microsoft now has a specific solution for doing hosted Exchange and Windows Hosting in general and PSS (now CSS) was often having issues fixing problems caused by people following the hosting guidelines.

However, many large companies have a need for address list segregation, which is one of the very TOP issues associated with hosted Exchange. Segregation basically means that you have one set of users seeing one address book in Outlook/OWA while another set of users sees a different one. So, Microsoft relented.

Once you have address list segregation, going the extra step to configure an entire virtual organization is a small step.

So, Dave Goldman, an Enterprise CSS guy, working with Tom DiNardo, a Technical Writer (both of whom I am privileged to know) wrote a white paper on the topic. Highly recommended. You can access it here.

Now, what does this NOT do for you that you might want in a hosted solution? Well, there are a number of things. It doesn't provide you with a custom OWA URL, or a custom Outlook Anywhere URL, etc. etc. It doesn't support clustering. While it's discussed, this solution doesn't do UPN updates. It doesn't provide any self-administration. It doesn't provide (although the hooks are there) for delegated administration. And so on.

But for what most people will ever need to do, it's great. This is a good thing to add to your Exchange toolbox and it shows some great examples of how to deal with some specific problems in PowerShell. Give it a look.

Until next time...

As always, if there are topics that you would like to see me discuss, please drop me a line and let me know!

Posted by michael | with no comments

A number of parameters for EMS (the Exchange Management Shell - which is just PowerShell v1 plus the Exchange snap-ins) require the specification of a multivalued property.

A multivalued property is just what it sounds like - a property that has multiple values.

A very common one is the RemoteIPRanges parameter for Set-ReceiveConnector.

It is common to see people asking how to specify multiple IP addresses and multiple IP ranges as a parameter to the cmdlet. It's actually pretty easy, once you know the trick.

Let's get some background. As you may know (or may not - just trust me here), PowerShell uses the comma character (",") as an operator - not as a simple argument separator. In many languages, this statement:

	callsub "a", 1, "hi"

would mean to call the subroutine named "callsub" with three parameters. But not in PowerShell! For PowerShell, this means to call the subroutine named "callsub" with ONE parameter - an array of three objects. This is easier to see by doing this:

	$a = "a", 1, "hi"

and the result may surprise you:

	IsPublic IsSerial Name                                     BaseType
	-------- -------- ----                                     --------
	True     True     Object[]                                 System.Array

To get the "other" behavior in PowerShell, you eliminate the commas:

	callsub "a" 1 "hi"

For me, this was one of the most difficult things to adjust to in PowerShell. But now that we are armed with that knowledge, it is pretty obvious how we get our desired behavior in with the RemoteIPRanges parameter - we separate each argument with a comma. For example:

	Set-ReceiveConnector Connector1 -RemoteIPRanges ("", "", "")

The parenthesis are just used to making the grouping clear. Now that we know that, once we've configured a ReceiveConnector, how do we update it without typing in all of those IP addresses again? We use PowerShell object references! This is a little tricky, but I bet it'll make sense when you see it.

	$a = Get-ReceiveConnector Connector1
	$a.RemoteIPRanges += ""
	$a | Set-ReceiveConnector

Pretty cool, huh!?

Until next time...

If there are things you would like to see written about, please let me know!

Posted by michael | 1 comment(s)
Filed under: , ,
More Posts Next page »