It's déjà vu all
Over again: we're back with
Before we get started, we have request to make: if any of you think that you're having a bad day, well, the author of today's haiku doesn't want to hear about it. Here's the kind of day that he's been having. He came in, sat down, and dutifully wrote today's Lync Server PowerShell haiku. He handed that off for publication, only to have it returned because he forgot one thing: the actual Lync Server PowerShell haiku. How can you write the Lync Server PowerShell haiku of the day without actually writing the haiku of the day? Don't ask.
Note. Several times in his life the author of today's haiku (well, assuming he actually bothered to write today's haiku) has gone to the store to get one thing; for example, he's gone to the store specifically to get milk. And, needless to say, when he gets back he realizes that he bought everything except milk.
OK, so he forgot the haiku. That's kind of silly, but it's not that big of a deal; after all, he did write the article that accompanies the daily haiku, didn't he? As a matter of fact, he did. But there was just one problem with that: he wrote about the Get-CsManagementStoreReplicationStatus cmdlet, which he already wrote about several weeks ago. Did he do that because Get-CsManagementStoreReplicationStatus is such a truly fascinating cmdlet that people want to hear about it over and over again? Well, no offense to the Get-CsManagementStoreReplicationStatus cmdlet, but, no: he did that because he's an idiot.
And because he is an idiot, that means he gets to write the Lync Server PowerShell haikus of the day today: the one about the Get-CsManagementStoreReplicationStatus cmdlet, and this hacked-together replacement haiku.
Note. So will today's original haiku, the one about the Get-CsManagementStoreReplicationStatus cmdlet, become a collector's item, just like the Beatles infamous butcher shop album cover? Probably.
OK, now that we have that out of the way, what cmdlet should we write about now? How 'bout this one: Get-CsManagementStoreReplicationStatus?
Good point; we'll save that one for another day. Today let's talk about the CsAdForest cmdlets (Disable-CsAdForest, Enable-CsAdForest, and Get-CsAdForest), partly because they're extremely exciting and guaranteed to generate tons of interest, but mainly because there really isn’t a lot to say about them. And that's important: after all, at the rate the author of today's haiku is going, he's probably going to have to write 4 or 5 more haikus before the day is out.
Perhaps the most interesting thing about the CsAdForest cmdlets is this: you can live a long and happy life without ever running any of these cmdlets.
Note. It's true: the American artist Grandma Moses lived to be 101 years old and, to the best of our knowledge, never once ran any of the CsAdForest cmdlets.
Nor, to the best of our knowledge, did she ever paint the exact same picture twice.
So what are these cmdlets for if you might never, ever run them? Well, primarily these cmdlets are used for installing and uninstalling Lync Server. As you probably know, before you can install Lync Server, you need to make a number of changes to Active Directory; this includes doing such things as:
· Creating objects and display specifiers specific to Lync Server.
· Creating universal security groups needed to manage Lync Server 2010.
· Granting global settings object access permissions to these security groups.
Typically, these tasks are handled by the Lync Server Setup Wizard: you start up the Wizard, you walk through the steps, and the Wizard (which is definitely a friendly Wizard, kind of like Harry Potter) will do all your forest prep for you. In other words, there's typically no need for you to run the Enable-CsAdForest cmdlet. The same thing is true if – gasp! – you ever decide to uninstall Lync Server. Most likely you won't need to manually run the Disable-CsAdForest cmdlet; instead, there are automated procedures that will remove all the changes that Enable-CsAdForest made to Active Directory.
But hey, you never know, right? Suppose one of these automated procedures runs into problems? That's OK; that's why the CsAdForest cmdlets are there. For example, if you want to verify that your Active Directory forest has been properly prepped for Lync Server you can simply run the Get-CsAdForest cmdlet:
If you get back the value LC_FORESTSETTINGS_STATE_READY then the forest has been properly prepped. If you get back the value LC_FORESTSETTINGS_STATE_NOT_READY then the forest hasn't been properly prepped.
Let's say that you do get back the value LC_FORESTSETTINGS_STATE_NOT_READY. Is that any reason to panic? No, not unless you like to panic. If you'd prefer not to panic, you can always call the Enable-CsAdForest cmdlet:
This cmdlet, incidentally, can be run at any time. Awhile back we did an experiment where we deleted one of the required Active Directory security groups; without that group, Lync Server no longer worked the way it was supposed to. Having screwed everything up (which seems to be something we're especially good at), we then ran Enable-CsAdForest, which checked the state of our Active Directory setup, realized that one of our security groups was missing, and created a replacement group for us. We don't really recommend that you go messing around with your Active Directory settings just so you can see if Enable-CsAdForest can fix the problems for you. But it's nice to know that the cmdlet exists, just in case something does get messed up.
As for the Disable-CsAdForest cmdlet, well, that cmdlet essentially wipes out everything that Enable-CsAdForest does. That sounds dangerous, and it is: if you run this cmdlet and you still have Lync Server installed you're going to have big trouble. Fortunately, though, there's a safeguard built into Disable-CsAdForest. Suppose you run this command:
Is that going to wipe out your installation of Lync Server? Probably not. Instead, the cmdlet is first going to check to see if any of the domains in your forest are still prepped for Lync Server. If they are, then the command will stop and tell you that you need to disable these domains (using the Disable-CsAdDomain cmdlet) before you can disable the forest.
Note. Of course, if you’re really gung-ho about wiping out the forest you can always include the Force parameter, which disables the forest regardless of whether you still have domains prepped for Lync Server. But unless someone way smarter than the author of today's haiku tells you to run Disable-CsAdForest along with the Force parameter, well, you probably shouldn’t do that.
Actually, we should clarify that a little: unless an official Microsoft support person tells you to run Disable-CsAdForest along with the Force parameter, you probably shouldn't do that. It doesn't help much to say this should only be done if someone way smarter than the author of today's haiku tells you to do that. All things considered, who isn't way smarter than the author of today's haiku?
Keep in mind that Disable-CsAdForest doesn’t uninstall Lync Server. All it does it remove all the Lync Server-specific changes that were made to Active Directory.
Got all that? Excellent. We'll see you all again on Monday.
Note. Well, unless it turns out that we already wrote about the CsAdForest cmdlets. In that case, we’ll see you again in a few hours.