Office Communications Server
Managing OCS 2007 R2 from the Command Line
Greg Stemp and Jean Ross
At a Glance:
- Configuring OCS 2007 R2 with LCSCmd.exe
- Prepping Active Directory for Office Communications Server
- Creating the Enterprise pool and activating server roles
- PWorking with certificates
There's a spider under the sofa. It peeked out a moment ago, then went back. It's a very large spider, at least in the eyes of one of us. We're going to pretend it's not there, and maybe it will stay put. Let's do something to take our minds off of it. The more confusing and complicated that something is, the better.
And what's more confusing and complicated than installing and configuring Microsoft Office Communications Server (OCS) 2007 R2? OK, we probably shouldn't have said that. To clarify, OCS 2007 R2 is a little complicated, but that's the nature of a product that encompasses so much.
On the bright side, it comes with a very nice setup wizard that walks you through all of the steps of installation and configuration. And on the brighter side, OCS 2007 R2 also comes equipped with a command-line utility named LCSCmd.exe that allows you to install and configure the product without the use of a wizard.
The spider is peeking out from under the sofa again. We'll continue to ignore it long enough to answer the question you're probably thinking: what's so bright about using a command-line utility rather than a wizard? We wondered that, too, so we asked the people we work with who seem to have some idea of what they're doing.
The answer has to do with deploying software within an enterprise. Command-line utilities, such as LCSCmd, can help to automate processes and allow for quick recovery of an application if there is a hardware failure. This made a certain amount of sense to us, so we decided that we should introduce you to LCSCmd.
So here we go. (And there goes the spider. No. Wait. It's back under the sofa again.) As we just mentioned, LCSCmd is a tool that allows you to set up and configure OCS from the command line. It accepts parameters that tell it what you want to do.
We're not going to go over them all here; there's a command-line reference
nearly 100 pages long that details that. We're just going to show you a few key commands and explain what they do. In addition, we'll show you some of the commands and parameters that are new in Office Communications Server 2007 R2.
OCS works closely with Active Directory. Before OCS can even be installed, Active Directory has to be ready for it. (Keep in mind that most of this can be done from the setup wizards, but we're showing you the command-line version anyway.)
To get Active Directory ready, you need to prep the schema, forest, and domain. Prepping Active Directory means we're adding attributes that OCS requires, things such as whether someone is enabled in the system to use OCS, whether a person's communications should be archived, and the version information of the server. To prep the schema, type this at the command line:
LCSCmd /Forest /Action:SchemaPrep
Does it get any easier than that? Actually, it does. These commands are not case sensitive, so we could have entered it like this:
lcscmd /forest /action:schemaprep
To prep the forest and domain, do the exact same thing, except use an action of ForestPrep for the forest, and for the domain use /Domain rather than /Forest with an action of DomainPrep. You know, like this:
lcscmd /forest /action:forestprep
lcscmd /domain /action:domainprep
Those three simple steps will get Active Directory all ready to go. Keep in mind that most of the commands in this article have more parameters than we're showing you here. There are far too many optional parameters to explain in this article, so you'll have to look at that 100-page document to get all the information. Or you can check the command-line syntax help, like this:
lcscmd /forest /action:schemaprep /?
You simply type the action you want to know more about followed by /? to get a list of all the possible parameters for that particular action.
Speaking of help, how did that spider get across the room? We hope there's not more than one. There it goes into the bookshelf.
Every time you run a command using LCSCmd, a log file is created. A log file will look something like the file shown in Figure 1. Unless you specify a name and location for this file by using the /L parameter (followed by, of course, the name and location of the log file), the log file will be saved to the %temp% folder. The name of the file will be a mixture of the command and the date. For example, run this command:
LCSCmd.exe /Forest /Action:CheckSchemaPrepState
Figure 1 Log file created by LCSCmd
If you ran this command on December 19, 2008, at 12:42 a.m., your log file will be here:
If you want to check a log and you don't remember exactly what time it was, just look in the %temp% folder and you can probably figure it out. Plus LCSCmd helps out by displaying the name of the log file as part of its output to the command window (see Figure 2).
Figure 2 Command window output
In case you're wondering what that previous command does, (you know, the one where the CheckSchemaPrepState action is run against the Forest), it checks the schema prep state of the forest. OK, that one was a little bit obvious. But what exactly does it mean to check the schema prep state? It is simply the process that makes sure that everything in the schema is ready for an installation of OCS.
After you run LCSCmd to do a SchemaPrep, it's not a bad idea to follow that with a CheckSchemaPrepState run just to make sure all went well and to get a detailed report of the state of the schema. You can do the same thing for ForestPrep and DomainPrep; simply use the actions CheckForestPrepState and CheckDomainPrepState, respectively. Like this:
LCSCmd.exe /Forest /Action:CheckForestPrepState
LCSCmd.exe /Domain /Action:CheckDomainPrepState
Remember earlier in the article where we said those three lines were all you needed in order to get Active Directory ready? Well, that's not entirely true. There's one more thing you need to do before Active Directory is ready for OCS.
If you're installing Enterprise Edition, you need to create an Enterprise pool. Enterprise Edition requires several servers, including one or more front-end servers and a back-end database server, plus (in most cases) a hardware load balancer. A pool is how these servers are grouped together.
The command for creating a pool is a little more complicated than the commands we've seen so far. Take a look:
LCSCmd /Forest /Action:CreatePool /PoolName:Pool01
This action takes place on the Active Directory forest, so you start by specifying the Forest parameter. (Don't spiders belong in the forest? They definitely don't belong in a bookshelf.) Next comes the action to create a pool, which is CreatePool. After that you enter the PoolName using whatever name you want for your pool.
Every pool needs a back-end database. (OCS uses this database in order to store user information.) When we create the pool, we use the PoolBE parameter to tell the pool which database that is and where it is. Finally, we need to put in some paths that will tell the pool where presentation content, meeting metadata, application data, and client update information is going to be stored. (To find out what all of those things are, you will actually have to go in and read the official documentation and get to know the product a little. Hey, we can't cover everything in this one article.)
OCS comes with a lot of different server roles, such as the Application Host, Mediation server, Archiving server, and Web Components server. A server role doesn't start working simply because you install it; you also need to activate it. And this just happens to be something else you can do from the command line by using LCSCmd.
Here's an example of a command that activates the Application Host:
LCSCmd /AppServer /Action:Activate /PoolName:Pool01
All we did was specify the server role, in this case AppServer for Application Host, and follow that with the action Activate. For an Enterprise installation, we include the pool name and password. Activating other server roles is done in a similar way, as they all use the Activate action.
In case you were wondering (you probably weren't, but just in case), using AppServer as our example wasn't a random choice. We used that one because AppServer and all its actions are new in Office Communications Server 2007 R2.
One of the other actions you are able to perform on AppServer from LCSCmd is ActivateApp. It will activate whichever of the four applications—Conferencing Attendant, Conference Announcement Service, Outside Voice Control, and Response Group Service—you want to use.
Here's an example of a command to activate Outside Voice Control:
LCSCmd /AppServer /Action:ActivateApp
Notice we start by specifying AppServer, then we put in the action, ActivateApp. Next, we need the application ID. For Outside Voice Control the application ID is Microsoft.Rtc.Applications.Ccs. (See Figure 3 for a list of application IDs for all four applications.) Last but not least we enter our password and, presto, Outside Voice Control is now activated.
|Conference Announcement Service
|Outside Voice Control
|Response Group Service
We want to note that we're assuming you already know what some of these applications are. In case you don't and you're reading this article just to keep track of the spider, we'll tell you that Outside Voice Control connects mobile users to OCS. (We think the spider is still in the bookshelf, somewhere between Adventures of Huckleberry Finn and The Adventures of Tom Sawyer.)
As you might expect, a product that has to do with communications needs to have a lot of security built into it. Part of that security in OCS is the use of certificates. As you might have noticed, in this article we're not talking much about how and why you do things; there are thousands of pages of help documentation and a resource kit to do all of that. So we're not going to explain how certificates work in OCS—where you use them, why you use them, and so on. What we are going to do is show you how to use LCSCmd to work with certificates.
In OCS 2007, you could use LCSCmd to request a certificate as well as to import and export certificates. You can still do those things in OCS 2007 R2, but R2 adds the ability to assign a certificate to a server. You can either assign the certificate after you have requested or imported it, or you can assign it at the same time you request or import it. Here's an example of requesting a certificate and assigning it to the current server, all in the same command:
LCSCmd /Cert /Action:Request /OU:Marketing
All commands pertaining to certificates begin with the Cert parameter. Here we're requesting a new certificate, so we've used the Request action. Next we need to specify the organization unit (OU) and organization (Org) to which this certificate will belong.
The next parameter, sn, is the subject name of the certificate. The subject name is the fully qualified domain name (FQDN) of the current server or pool, and in this example we've used the FQDN of the pool. For server roles that are on servers other than the front-end server, the FQDN of the server must be entered as the sn parameter value.
Now we put in our country, city, and state. The next parameter is the one that's new in OCS 2007 R2: Assign. Set the Assign parameter to True to immediately assign the certificate to the server or pool. Finally, we enter the name of the certification authority.
To assign a certificate that already exists, use the new Assign action, like this:
LCSCmd /Cert /Action:Assign /issuer:contoso.com
We're once again using the Cert parameter to let LCSCmd know we're working with certificates, and we're using an action of Assign to assign the certificate. Because the certificate already exists, we need to specify the Issuer (this is the common name of the certificate issuer), then we tell LCSCmd which certificate it is we're assigning by supplying the SubjectName of the certificate.
We have also included the optional Components parameter in our example. It's required if you're assigning the certificate to an Access Edge server (AP), a Web Conferencing Edge server (DP), or an A/V Edge server (MR). Here we're assigning it to the Access Edge server and the A/V Edge server.
Anybody know if there's some kind of security that will keep spiders out of your house? This spider now seems to have an interest in The Hitchhiker's Guide to the Galaxy.
There are a few more new parameters that have been added to OCS 2007 R2, but there's one in particular that just might come in handy from time to time: Broadcast Message. A broadcast message in OCS is an alert that is sent by the administrator to all users (technically they're called Session Initiation Protocol, or SIP,-enabled users) or users hosted on a specified pool.
Here's an example of a broadcast message:
LCSCmd /server /action:BroadcastMessage /Role:Proxy
/Message:"The system is going down for maintenance
at 7:00 PM PST."
This action is related to a particular OCS server role, so we've used the Server parameter. The action is, logically enough, BroadcastMessage. Next, we specify which server role we are working with. In this instance we've specified the Proxy server role, but we could also have specified Standard Edition server (SE), Enterprise Edition server (EE), Workgroup Proxy server (WorkGroupProxy), or Edge server (AP).
Finally, we include the message. And that's it. Uh-oh, that's not it for the spider—it looks like it's coming this way.
Keep in mind that this message isn't necessarily designed for immediate notifications, such as "The system is going down for maintenance in five minutes," simply because in a very large pool it can take some time to get the message to everyone. For example, in a pool with 50,000 users signed in, the message can take almost half an hour to get out to everyone. Needless to say, the message that the system is going down in five minutes won't be very useful half an hour later.
Just one more note about using LCSCmd. You can run the command remotely. Simply follow the first parameter with the FQDN name of the server you're working with. For example, if you're working remotely against a forest, your command would begin like this:
LCSCmd /Forest:contoso.com …
That's about it for our introduction to LCSCmd. That's about it for our spider, too. We'd like to say that no spiders were harmed in the writing of this article, but unfortunately we can't. Sorry about that.
Against all odds, Greg Stemp and Jean Ross work for Microsoft.