Don't play with matches.

Oh, and don't use CS Voice

Configuration.

As it turns out, today is definitely not a good day for the author of today's haiku. (Would it qualify as a horrible, terrible, no good, very bad day? It just might.)

So what's so bad about today? Well, today is the last day that the author of today's haiku gets to spend in Park City, UT. Tomorrow, he has to pack up the car, load the bikes on the bike rack, and head for home.

Now, we should probably note that the author of today's haiku has nothing against Seattle; it's just that he's gotten used to a different kind of lifestyle here in Park City. For example, he has a bike trail that runs past the condo where he and his wife have been staying; to go on a bike ride all he has to do is walk out the back door and hop on the trail. (Even better, he can ride his bike to the grocery store and back, all without leaving the bike trail.) Of course, admittedly, if he wants to hike through the mountains he will have to get in the car and drive for 15-20 minutes. How does that compare to Seattle? Let's put it this way: at certain times of the day, it might take 15-20 minutes before he can actually get out of his own driveway.

And then there's the all-new, no-meeting work schedule that he's adopted. On a typical day, he gets up reasonably early, and starts to work. (And there's another thing. In Seattle, it takes him about 30 minutes to get to work each morning and 30-40 minutes to get back home each evening. In Park City, it takes him about 0 minutes to get to work each morning and 0 minutes to get back home each evening.) When he gets tired of working – well, OK, when he gets tireder of working – he simply hops on the bike or goes for a hike. Later that evening, he'll get back on the computer and work a little more. He still puts in his hours, but during the boring parts of the day rather than the warm, sun-drenched afternoons.

A body could really get used to that.

But you know what they say: all good things must come to an end, and tomorrow the author of today's haiku heads for home, back to working every day from 7:00 AM to 4:00 PM, and back to a lawn that hasn't been mowed in a month. Hurray!

Before we head back to Seattle, however, we do have one piece of unfinished business to take care of: we need to talk about the CsVoiceConfiguration cmdlets (Get-CsVoiceConfiguration, Remove-CsVoiceConfiguration, and Set-CsVoiceConfiguration). And what is it we want to say about the CsVoiceConfiguration cmdlets? Just this: to be perfectly honest, you shouldn't bother using the CsVoiceConfiguration cmdlets.

Many years ago, when the author of today's haiku worked at the University of Washington, he worked with several people who were very skeptical when it came to Microsoft and Microsoft products. (!) Their theory was that people at Microsoft kept all the good stuff for themselves (and their corporate partners), and made their not-quite-as-good software available to the general public. Which, needless to say, was an easy-enough argument to refute … at least until Microsoft Bob hit the shelves.

At any rate, you might be thinking, "Why don't they want us to use the CsVoiceConfiguration cmdlets? Is it because those people at Microsoft want to keep these really cool, really useful cmdlets to themselves?" If you are thinking that, well, we have an answer to that question: No. As it turns out, the CsVoiceConfiguration aren't all that cool and they aren't all that useful. Instead, they do pretty much the same things that the CsVoiceTestConfiguration cmdlets do. Only not quite as much, and not quite as well.

We won't talk much about voice test configuration today; that's already been covered in Haiku 160. For now, we'll simply quote from Haiku 160 and note that voice test configurations "… allow you to set up scenarios that you can use to ensure that given a specific telephone number, that number would be correctly normalized and would follow the expected voice policy, voice route, and dial plan." All in all, a pretty handy little thing to have.

The only problem with voice test configurations is that we've provided two different sets of cmdlets to manage these settings: the CsVoiceConfiguration cmdlets and the CsVoiceTestConfiguration cmdlets. Why do we have two different sets of cmdlets to manage these settings? Well, we can't provide the exact details simply because we don't know the exact details. All we know do know is this: originally we had the CsVoiceConfiguration cmdlets. Those cmdlets were eventually superseded by the CsVoiceTestConfiguration cmdlets. However, because the Lync Server Control Panel uses the CsVoiceConfiguration cmdlets in some way, shape or form, we couldn't easily get rid of those cmdlets. And so, just like that, we ended up with two different sets of cmdlets to manage the exact same settings.

Like we said, however, the CsVoiceTestConfiguration cmdlets tend to manage these settings a little better. For example, suppose you want to review a collection of all your voice test configurations. One way to do that is to use the Get-CsVoiceConfiguration cmdlet:

Get-CsVoiceConfiguration

In turn, that will bring back data similar to this:

Identity                : Global

VoiceTestConfigurations : {Name=TestConfig1;DialedNumber=5551212;TargetDialplan=Global;TargetVoicePolicy=Global;ExpectedTranslatedNumber=+5551212;ExpectedUsage=;ExpectedRoute=,Name=TestConfig2;DialedNumber=5551219;TargetDialplan=Global;TargetVoicePolicy=Global;ExpectedTranslatedNumber=+5551219;ExpectedUsage=;ExpectedRoute=}

Of course, it's possible that some of you might find that output a little difficult to read. In that case, you might use this command (and the Get-CsVoiceTestConfiguration cmdlet) instead:

Get-CsVoiceTestConfiguration

Do that, and you'll get back output that looks like this:

Identity                 : TestConfig1

Name                     : TestConfig1

DialedNumber             : 5551212

TargetDialplan           : Global

TargetVoicePolicy        : Global

ExpectedTranslatedNumber : +5551212

ExpectedUsage            :

ExpectedRoute            :

Identity                 : TestConfig2

Name                     : TestConfig2

DialedNumber             : 5551219

TargetDialplan           : Global

TargetVoicePolicy        : Global

ExpectedTranslatedNumber : +5551219

ExpectedUsage            :

ExpectedRoute            :

Needless to say, we're not telling you not to use Get-CsVoiceConfiguration, we're just – oh, wait. We guess we are telling you not to use Get-CsVoiceConfiguration.

The difference between Set-CsVoiceTestConfiguration and Set-CsVoiceConfiguration is equally dramatic. Suppose you need to change the DialedNumber for TestConfig1. Here's how you do that using Set-CsVoiceTestConfiguration:

Set-CsVoiceTestConfiguration -Identity TestConfig1 -DialedNumber 14255551219

And how do you perform that same task using Set-CsVoiceConfiguration? Like this:

$x = Get-CsVoiceConfiguration

$y = $x.VoiceTestConfigurations | Where-Object {$_.Name -eq "TestConfig1"}

$y.DialedNumber = 14255551219

Set-CsVoiceConfiguration -Instance $x

And no, we aren't going to explain how those commands work. Why not? Because we don't want you to use those commands. We want you to use this command instead:

Set-CsVoiceTestConfiguration -Identity TestConfig1 -DialedNumber 14255551219

Now, admittedly, we have been a bit harsh on the CsVoiceConfiguration cmdlets: it's not their fault that they aren't the most user-friendly cmdlets ever created. With that in mind, we will say that the Remove-CsVoiceConfiguration cmdlet can actually be quite useful, albeit in one specific instance: any time you want to delete every one of your voice test configurations. If you really do want to get rid of all your voice test configurations then you can do so using this command:

Remove-CsVoiceConfiguration -Identity Global

To be honest, we aren't sure how often that situation will crop up but, if it ever does, you'll now be ready for it.

Remove-CsVoiceTestConfiguration -Identity TestConfig1

So is that all there is to say about the CsVoiceConfiguration cmdlets? Well, to be honest, that's probably way more than there is to say about the CsVoiceConfiguration cmdlets. But with an avowed goal to write a haiku about each Lync Server PowerShell noun, well, we had to cross the CsVoiceConfiguration bridge sooner or later.

And speaking of crossing bridges, we'll be doing a lot of that tomorrow. (And crossing a few mountain passes as well.) But don't worry: there won't be a haiku tomorrow, but there will be one come Monday morning.

And who's more excited about that: the author of today's haiku, or the readers of today's haiku? Interesting question ….

I only have eye

Lashes for you. And for you,

Outbound translations.

If you're like most people then each and every morning, as you climb into your car and prepare to go to work, you think, "You know, this car is pretty good: it runs well, I've never had any problems with it, and it gets awfully good gas mileage. And yet still, I don't think I'll ever be able to look past its one major flaw: my car doesn't have eyelashes."

You've been there before, haven't you? Well, so has the author of today's haiku, and he got so desperate that he actually decided to trade in his current car and get a new one, a new one that had eyelashes. Unfortunately, though, he couldn't find a car that had eyelashes; apparently they sell out so quickly that the dealers can't even keep them on the lot. Disappointed? That's putting it mildly.

At any rate, the author of today's haiku had resigned himself to never having a car with eyelashes, or at least he had resigned himself to that until he attended the recent Miner's Day Parade in Park City, UT.

Like most people, the author of today's haiku assumed that the highlight of the parade would be the dancing bowling pin. (Obviously.) As it turned out, however, there was something even better than the dancing bowling pin: cars with eyelashes! Even better, these weren't high-priced custom cars that only a Tom Cruise or a George Clooney could afford: these were regular old cars tricked out with carlashes, carlashes that just about anyone can afford!

Of course, after learning that you can buy eyelashes for your car, your next question is undoubtedly going to be this: can I also buy eyelashes for my Lync Server PowerShell cmdlets? Sadly, the answer is no; in fact, you can't buy any accessories for any of the Lync Server PowerShell cmdlets. But that's OK; we like to believe that our cmdlets stand on their own, without the need for gaudy accessories.

Give you an example? OK; what about the CsOutboundTranslationRule cmdlets (Get-CsOutboundTranslationRule, New-CsOutboundTranslationRule, Remove-CsOutboundTranslationRule, and Set-CsOutboundTranslationRule)? You can't buy eyelashes for the CsOutboundTranslationRule cmdlets, nor can you buy handbags, scarves, earrings, or anything else that might jazz up the appearance of the CsOutboundTranslationRule cmdlets. On the other hand, you can use the CsOutboundTranslationRule cmdlets to create outbound translation rules, rules that can turn an E.164-formatted phone number used by Microsoft Lync to a phone number format used by your PBX (private branch exchange) system. And we'd like to see any car be able to do that, eyelashes or no eyelashes!

Well, OK, maybe Volvos. But other than that, we don't know of any cars that can create outbound translation rules.

So what did we say that outbound translation rules were again? Well, as you know, any time you make a phone call using Microsoft Lync Server the phone number you call gets translated to the E.164 format. For example, when you call the local Seattle phone number 555-1219, that number gets translated to this:

+12065551219

In that translated number, the first 1 represents the country code (US), the 206 represents the area code for Seattle, and the 5551219 represents the phone number itself.

So what's wrong with that? Nothing. Well, actually, one thing: not all PBX systems recognize the E.164 format. If your PBX system doesn't understand E.164, then you're going to have to convert that E.164 number to a phone number that the PBX system does understand. And that's the reason we need outbound translation rules.

Let's show you a simple example of what we mean. First, let's show you a command that creates an outbound truncation rule:

New-CsOutboundTranslationRule -Parent global -Name SeattleSevenDigit -Description "Convert to seven digits" -Pattern '^\+1206(\d{7})$' -Translation '$1'

There are two parameters of primary importance here: Pattern and Translation. The Pattern parameter describes the pattern we want to match. In this case, we want to capture local phone numbers that are dialed without using the country code or area code; in other words, local numbers dialed like this:

5551219

As we've already seen, Lync Server (probably using voice normalization rules you created earlier) will convert that dialed number into an E.164 number:

+12065551219

Of course, the problem with that is that our PBX system doesn't understand E.164 numbers. Therefore, we need to convert that number to a number that the PBX system does understand. In this simple example, we're assuming the PBX system can handle a number like 5551219. Therefore, we simply translated the E.164 number back to the number originally dialed: 5551219. (In a regular expression, the symbol $1 essentially means, "Use the original value."

As long as we're on the subject, it's important that you surround the Pattern and the Translation values with single quote marks: '$1'. If you use double quote marks around the value (or no quote marks) you'll get an error message like this:

New-CsVoiceNormalizationRule : Cannot create item "Global/SeattleSevenDigit": "Value cannot be null.

Parameter name: value"

Why? Well, in a case like that (e.g., "$1"), PowerShell is trying to use the value of a variable named $1. Most likely you don't have a variable named $1, which means you're trying to assign a null value to the Translate parameter. In turn, that means you're trying to convert the E.164 phone number into nothing. And very few PBX systems know how to dial nothing.

By contrast, when you enclose $1 in single quotes, Windows PowerShell uses the literal value: $1. In other words, your finished rule will have these property values:

Identity            : Global/SeattleSevenDigit

Priority            : -1

Description         : Convert to seven digits

Pattern             : ^\+1206(\d{7})$

Translation         : $1

Name                : SeattleSevenDigit

If that doesn’t make much sense, well, for the time being at least, just use single quotes and don’t worry too much about it.

And what if you PBX system requires the area code, even for local numbers? That's fine: just include the 206 in your translation. In other words:

New-CsOutboundTranslationRule -Parent global -Name SeattleSevenDigit -Description "Convert to seven digits" -Pattern '^\+1206(\d{7})$' -Translation '206$1'

The Translation 206$1 simply says, "Dial 206 followed by the number the user actually dialed (that is, $1)."

It’s like child's play … well, assuming that you were a pretty smart child.

That, in a nutshell, is how outbound translation rules work, and how the New-CsOutboundTranslationRule cmdlet works. We won't spend a lot of time talking about the remaining cmdlets in the CsOutboundTranslationRule: you can probably guess what Get-CsOutboundTranslationRule, Remove-CsOutboundTranslationRule, and Set-CsOutboundTranslationRule do. One thing that we will note, however, is the Priority parameter, a parameter found on both New-CsOutboundTranslationRule and Set-CsOutboundTranslationRule. It's possible that – depending on your setup – a dialed number could meet more than one translation rule. If so, the Priority parameter lets you specify which rule gets applied first. By default, the first translation rule you create is assigned priority 0, the second rule is assigned priority 1, and so on:

Now, suppose you'd prefer that Rule3 have the highest priority. In that case, you can just use the Set-CsOutboundTranslationRule cmdlet to change the Priority for that rule:

Set-CsOutboundTranslationRule -Identity "global/Rule2" –Priority 0

Do that, and Rule3 will now have the highest priority, and the other rules will have their priorities adjust accordingly:

We doubt that even a Volvo could do that.

That's about all we have time for today. As you might expect, outbound translation rules have the potential to get a bit complicated, especially if you try to apply least-cost routing. If that's of interest to you, you might check out a very cool online utility that can do least-cost calculations (and create outbound translation rules) for you. It's a pretty slick little tool, although we were a little disappointed that it wouldn't write today's haiku for us. Maybe in the next version.

Oh, and speaking of what's coming next, here's what's coming next: lips for your car. Hey, we couldn't make up something like that even if we wanted to.

See you tomorrow.

Bah-bah black sheep, have

You a reason to run the

ACP commands?

This past weekend was an exciting one for the author of today's haiku: he attended the Soldier Hollow Sheepdog Championship. Why was that so exciting? Well, when it comes to spectator sports, the author of today's haiku has always had two goals: 1) to go to the Rose Bowl and watch the University of Washington beat somebody – anybody­ – from the Big Ten Conference (which, for those of you who graduated from a Big Ten school, actually has twelve members); and, 2) to attend a Sheepdog Championship. A few years ago the author and his son watched as the UW whipped Purdue in the Rose Bowl. And now, after this past weekend, well ….

To be perfectly honest, however, the Sheepdog Championship was actually pretty interesting, interesting enough that the author of today's haiku now considers himself something of an expert on sheepdog trials. We never really recommend that you ask him questions about Lync Server or Lync Server PowerShell, but if you have questions about sheepdog trials – and on any component of the trials, from the outrun to the gather to the shed – just send them in and he will be happy to answer them. No doubt he'll answer them incorrectly, but he'll be happy to answer them nevertheless.

One thing that he was especially interested in was the terminology used by the sheepdog handlers ("Come bye"). If you've ever seen the movie Babe (and if you haven't, you should stop whatever you're doing and go see it), then you might recall the shepherd saying, "That'll do, Pig. That'll do." As it turns out, "That'll do" is standard terminology used by a sheepdog handler: it means that everything is fine, and that the dog can relax. The author of today's haiku was intrigued by that because, several years ago, he was helping his son with a project and the author asked his son if they were about ready to wrap things up. "That'll do, Pig," said his son. "That'll do."

At any rate, the sheepdog trials were kind of cool, and the border collies competing were remarkably intelligent. Are border collies smart enough to write a daily haiku about Lync Server PowerShell? Actually, border collies are smart enough not to write a daily haiku about Lync Server PowerShell. You know, sometimes the author of today's haiku wishes he was a border collie.

Of course, so do the people he works with.

At any rate, all of that represents our clever lead-in to – you got it – today's haiku about Lync Server PowerShell. Today we're going to talk about the CsUserAcp cmdlets: Get-CsUserAcp, Remove-CsUserAcp, and Set-CsUserAcp.

And the first thing we want to talk about is this: you probably don't want to use these cmdlets. The CsUserAcp cmdlets are really intended for use with the Office 365 version of Microsoft Lync, and not really intended for use with Microsoft Lync Server 2010. They work in Lync Server 2010, and, if you want to, you can use them for record-keeping purposes. But they don't provide true integration between Lync Server and an audio conferencing provider (ACP).

Oh, right: we should probably mention that the CsUserAcp cmdlets are designed to provide integration between Lync Server (or at least the Office 365 version of Lync) and an audio conferencing provider. If you aren't familiar with the term, an audio conferencing provider is a third-party company that provides organizations with conferencing services. Among other things, ACPs provide a way for users located off site (and not connected to the corporate network or the Internet) to participate in the audio portion of a conference or meeting. In addition to that, audio conferencing providers often provide high-end services such as live translation, transcription, and live per-conference operator assistance. It all depends on what you need to do and, to be honest, what you're willing to pay for.

In Office 365, you'll eventually be able to use Windows PowerShell to assign audio conference providers to your users, and then to management those assignments once they've been made. (Before you ask, no, this capability is not yet available to Office 365 administrators.) In Lync Server 2010, you can use the CsUserAcp cmdlets simply to keep track of which ACPs have been assigned to which users. Keep in mind, however, that this is purely for bookkeeping purposes: if you assign an ACP to a user using Set-CsUserAcp, the cmdlet won’t, say, notify the audio conferencing provider of the change. To be honest, at this point in time anyone using a third-party audio conferencing provider would probably be better off tracking user data using the ACP's software instead of the CsUserAcp cmdlets. But hey, who are we to judge, right?

If you decide that you really, really want to use the CsUserAcp cmdlets, you can assign an ACP to a user by using a command similar to this:

Set-CsUserAcp -Identity "Ken Myer" -TollNumber "14255551298" -ParticipantPassCode 13761 -Domain "fabrikam.com" -Name "Fabrikam ACP" -TollFreeNumbers "18005551010", "18005551020"

As you can see, we assigned Ken Myer to the audio conferencing provider Fabrikam ACP. In doing so, we assigned Ken a toll number, a pass code, and a pair of toll-free numbers. (Where do all these values come from? From the audio conferencing provider.) About the only thing to really note here is the format used for the telephone numbers: it's numbers-only, with no hyphens, no parentheses, and no TEL:+ prefix.

Which means it's actually easier than assigning other types of phone numbers.

And that's really all there is to it. Do you actually want Ken Myer to have an account with two audio conferencing providers? That's fine: just assign him a second provider, like so:

Set-CsUserAcp -Identity "Ken Myer" -TollNumber "12065551219" -ParticipantPassCode 09841 -Domain "contoso.com" -Name "Contoso ACP" -TollFreeNumbers "18005550712"

If you now look at the ACP information for Ken Myer, you'll see that he's been assigned to both Fabrikam ACP and Contoso ACP.

Oh, good point: how do you look at the ACP information for Ken Myer? We'd suggest using the Get-CsUserAcp cmdlet, like so:

Get-CsUserAcp -Identity "Ken Myer"

If you want to look at all the users assigned to Contoso ACP you can use a command like this one:

Get-CsUserAcp | Where-Object {$_.AcpInfo -match "Contoso ACP"

And while we're at it, here's another handy little command, one that returns a list of all the users who have not been assigned an audio conferencing provider:

Get-CsUserAcp -Filter {AcpInfo -eq $Null}

And if you want to remove the audio conferencing providers assigned to Ken Myer, well, that's what the Remove-CsUserAcp cmdlet is for. This command removes all the ACPs assigned to Ken Myer:

Remove-CsUserAcp -Identity "Ken Myer"

And this one removes just the Contoso ACP provider, leaving any other providers assigned to Ken Myer as-is:

Remove-CsUserAcp -Identity "Ken Myer" -Name "Contoso ACP"

We could go on, but, again, these probably really aren't cmdlets you'll ever need to use. If you want to see more examples, check the help topics for Get-CsUserAcp, Remove-CsUserAcp, and Set-CsUserAcp.

Is there anything else we want to say about the CsUserAcp cmdlets? Nope. That'll do, folks. That'll do.

See you tomorrow.

We're going down where?

Couldn't we just install a

Database instead?

Well, we're back for another edition of the Lync PowerShell haiku of the day. That might not seem all that momentous to you, but there were several times yesterday afternoon when the author of today's haiku wasn't totally sure he would be back to do another edition, at least not today. That's because, for reasons they still don't fully understand, yesterday afternoon the author and his wife took their bikes out to the Deer Valley ski resort and decided to ride those bikes down Bald Mountain, all 9400 feet of it. How much experience did the author and his wife have in riding bikes down 9400 feet of steep, twisty, rock-strewn ski resort trails? Zero. How much experience should they have had in riding bikes down 9400 feet of steep, twisty, rock-strewn ski resort trails? That's hard to say for sure. But way more than zero.

Nevertheless, the author and his wife made it down the mountain successfully, and in one piece. (Well, minus a little bit of skin they left here and there.) It's not like they flew down the mountainside, and it's not like they didn't have an occasional mishap: their bikes did hit the ground a couple of times. (Which is apparently to be expected: the real mountain bike riders all wore helmets with full face shields, knee pads, shin guards, elbow guards, and any other kind of guard/body armor they could think of.) But they made it and, when it comes to riding bikes down mountains, that's all that really matters.

If you're wondering what the best part of the experience was, it had to be this: the author of today's haiku had just finished maneuvering down some incredibly-steep, incredibly-slick drop-offs, drop-offs so steep and slick the mountain goats wouldn't even go down them. ("You go down it." "No way, man, you go down it.") Having successfully navigating these hairpin, hair-raising turns, the author finally reached one of the few flat and smooth sections of the trail … and promptly crashed.

That's just the way he tends to do things.

Of course, by now you must be wondering what the author of today's haiku could possibly do to top a thrilling and exciting day like the one he had yesterday. Well, to be completely honest, he couldn't think of a single thing that would top a thrilling and exciting day like the one he had yesterday. So he decided to write about the CsDatabase cmdlets instead: Install-CsDatabase and Uninstall-CsDatabase.

Before we get started, there are a couple of things that we should note about the CsDatabase cmdlets. For one, these cmdlets are kind of like fire extinguishers: it's great to have a fire extinguisher in your house, but it's even better if you never have to actually use that fire extinguisher. That's pretty much the case with the CsDatabase cmdlets. These cmdlets are available if something bad happens: you set up Lync Server but, for some reason, one of the databases does not get installed, or maybe the computer hosting your Archiving database gives up the ghost and you now need to move that database elsewhere. That's all well and good, but if you can manage to live out your entire life without running either of the CsDatabase cmdlets, well, so much the better.

The second thing we should note is that the CsDatabase cmdlets (especially the Install-CsDatabase cmdlet) can get a bit complicated: Install-CsDatabase has more than 20 parameters. Therefore, we aren't going to try and touch every possible scenario and every possible parameter in today's haiku. See the appropriate help topic (Install-CsDatabase or Uninstall-CsDatabase) if you need more detailed information.

Instead, when it comes to Install-CsDatabase we'll just note that there are three basic ways to run the cmdlet:

Option 1 -- Run the cmdlet without including any parameters that specify the database paths. If you run Install-CsDatabase without either the DatabasePath or the UseDefaultSqlPath parameter, then the cmdlet uses a built-in algorithm to choose the storage location for the database logs and data files. Is that a good thing? Yes: that way you don't have to worry about figuring out where the logs and files go, and you don't have to figure out the syntax for correctly specifying those locations.

Of course, there is one catch here: the built-in algorithm only works with a standalone SQL server; it will not work with a SQL cluster. To install a database on a SQL cluster your command must include either the DatabasePath or the UseDefaultSqlPath parameter.

For example, if you want Install-CsDatabase to install the appropriate databases (as read in from your Lync Server topology) then all you have to do is run a command like this one:

Install-CsDatabase -Configured Databases -SqlServerFqdn atl-sql-001.litwareinc.com

This is typically the way an administrator will use Install-CsDatabase: you let the cmdlet determine the log and data file locations, and you even let the cmdlet figure out which databases to install. That gives you more time to do something really fun, liking falling off your bike.

Option 2 -- Run the cmdlet along with the DatabasePath parameter. When you include the DatabasePath parameter, the built-in algorithm is not used to choose the storage location for the database logs and data files. Instead, administrators can select the location for these logs and data files. To install both data files and SQL logs in the same location, simply specify the path to the folder where this data should be stored. For example:

Install-CsDatabase -Configured Databases -SqlServerFqdn atl-sql-001.litwareinc.com -DatabasePath C:\SqlData

To store data files in one location and log files in a second location, specify the path to each folder, separating the two locations by using a comma (be careful not to put a blank space before or after the comma):

Install-CsDatabase -Configured Databases -SqlServerFqdn atl-sql-001.litwareinc.com -DatabasePath C:\SqlLogs,D:\SqlData

The log files will always be stored on the first location specified, while data files will be stored in the second location.

Now, that assumes that you only have two drives to use for your database. If you have more than two drives, well, things can get a little tricky. For more information, see the Microsoft Lync Server 2010 Enterprise Edition Deployment Guide.

Option 3 -- Run the cmdlet along with the UseDefaultSqlPaths parameter. If you do that, the built-in algorithm will (again) not be used to choose the storage locations for the database logs and data files. Instead, log and data files will be stored in the locations specified by the SQL Server defaults path (these paths must be configured in advanced by a SQL administrator). Data files will be stored in the default SQL data file location while log files will be stored in the default SQL log file location.

By the way, you don’t need to supply a parameter value when using UseDefaultSqlPaths; just including the parameter itself will suffice:

Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn atl-sql-001.litwareinc.com –UseDefaultSqlPaths

Got all that? Good. Now let's chat for a minute about Uninstall-CsDatabase, the cmdlet of choice if you need to remove a database. Suppose you need to get rid of your existing Archiving database. How can you do that? Here's one way:

Uninstall-CsDatabase -DatabaseType Archiving -SqlServerFqdn atl-sql-001.litwareinc.com

The preceding command will not only uninstall the Archiving database on atl-sql-001.litwareinc.com but it will also delete all the stores associated with that database. You say that sounds a little harsh? Well, OK. In that case, you might want to simply detach the database. When you detach the database, it will no longer be operational. However, the database stores will not be deleted; instead, the stores will remain in place and all the file locks imposed by SQL Server will be removed. Is that a good thing? You bet it is: that enables you to directly access the database files in order to do such things as copy those files to another computer.

And so how exactly do you detach a Lync Server database? That's easy: you just add the Detach parameter. You know, like this:

Uninstall-CsDatabase -DatabaseType Archiving -SqlServerFqdn atl-sql-001.litwareinc.com –Detach

It's as easy as falling off a mountain.

Something the author of today's haiku happens to know a little bit about.

See you all on Tuesday.

A long time ago, in a job far, far away, we used to send out a monthly newsletter to our subscribers that recapped what we’d done on our web site for the month and sometimes even provided a look ahead at what was coming. But, with progress comes change, and progress in this case means we can no longer send out monthly newsletters. So, here’s our version of the monthly newsletter: a blog post.

But hey, it’s not just any blog post. It’s a recap of what you might have missed here on the Lync Server PowerShell blog during the month of August if you weren’t paying close attention. We’d say it also includes what’s coming in September, but we’re not entirely clear on that just yet, so we’ll have to keep you in suspense.

What Happened at the Lync Server PowerShell Blog in August

An In-Depth Guide to Conferencing Policy Settings

Per-organizer and per-user settings for conferencing policies were making people’s heads spin. That was a little creepy so we decided to try to put a stop to it with this collection of articles.

Continue an Instant Messaging Conversation

We had already published an article about sending an instant message from a script. This article expands on that by allowing you to continue a conversation that you’d already started rather than starting a new one every time.

Haiku of the Day

We were on vacation this month, so we only managed to get out 18 new haikus rather than the typical 20-25. Sorry about that.

Here are the nouns for the cmdlets we covered this month:

From the Community

Here are some things from elsewhere in the Windows PowerShell and Lync Server world:

A History of the Microsoft Scripting Guys

Who would have guessed that Greg Stemp, the not-so-famous Lync Server PowerShell blog writer, was once the very famous Scripting Guy? Yes, it’s true, Greg was the creator of the Scripting Guys and the Script Center. Find out how it all began in this article by Don Jones.

Viewing and Reverting Default Global Policy Settings in Lync Server

This article, by Tim Harrington, explains how to reset global policies to their default values.

Tutorial: Test-CsAddressBookService (Lync Server 2010 PowerShell Cmdlet)

Desmond Lee walks you through how to use the Test-CsAddressBookService cmdlet to, well, test your Address Book service.

Want to see your article featured in our monthly wrap-up? Let us know what you’re posting by sending an email to cspshell@microsoft.com.