Haiku #183

  • [アーティクル]

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.

 

Note. While the CsDatabase cmdlets are kind of exciting, they don't quite compare with riding your bike down a mountain. On the other hand, you typically can run the CsDatabase cmdlets without losing any skin, or acquiring any bumps and bruises.

 

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 usethat 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.

 

Note. Monday, of course, is Labor Day, a US holiday dedicated to the "… social and economic achievements of American workers." What do the words "achievements" and "worker" have to do with the author of today's haiku? Nothing that we can think if. But he's taking Monday off anyway.

Comments

  • Anonymous
    May 21, 2012
    Hello Haiku, thanks for your great posting. I came across it, because i have problem with my RTCLOCAL databases on my front end server. After a reboot the XDS db on the RTCLOCAL Database ist corrupt and suspended. The CMS store (on the RTC instance on the same server) is running. Can i now recreate the RTCLOCAL db's on this front end and publish Topology again to make things run again? like: Install-CsDatabase -LocalDatabases –Clean –ForInstance RTCLOCAL