Today’s haiku writes
Itself: Import Legacy
Good news, everyone: today we’re not going to complain about the weather, we’re not going to complain about the Seattle Mariners (really, what’s the point?), and we’re not going to complain about missing out on National Doughnut Day. Instead, today the author of this haiku wants to tip his cap to his wife, who – with his help, of course – managed to accomplish her summer goal this past weekend.
A few months ago, the missus decided that – before the summer was out – she wanted to complete a 40-mile bike ride on a nearby mountain bike trail. Now, admittedly, hard-core mountain bikers might not consider this a real mountain bike trail; after all, the trail does not require you to ride across a wire strung across the Grand Canyon, pedal several miles underwater, or do any of the other things that real mountain bikers do. Still, the trail is not paved, it’s got its share of rocks and ruts and bumps and branches, and there are several miles of deep gravel that you have to slog through. That’s really – well, “fun” isn’t really the word we’re looking for, is it?
And, besides, 40 miles is 40 miles. When the author of today’s haiku was growing up in Kennewick, WA, the family would occasionally have to venture into Richland in order to do something. This always invoked the same reaction: “Richland?!? Why do we have to go to Richland? That’s too far!”
Richland, in case you’re wondering, is 9 miles from Kennewick – by car. On Saturday, the author of today’s haiku – and his wife – rode 40 miles on mountain bikes.
And, more importantly, lived to tell the tale.
Anyway, the point is this: the author’s wife set a goal for herself, and she achieved it. And let’s face it, there’s no better feeling than setting a goal for yourself and then achieving it.
Or so the author of today’s haiku has been told. He’s kind of been out of the goal-setting business for the past few years.
But that’s about to change: the author of today’s haiku has decided that he’s going to set a goal for himself and he’s going to achieve that goal. Is he going to ride, say, 60 miles on a mountain bike trail? Heavens no; that would be way too much work and take way too much time. Instead, he’s going to do the next-best thing: he’s going to write a haiku about the Import-CsLegacyConfiguration cmdlet!
So what exactly is the Import-CsLegacyConfiguration cmdlet? Well, along with its fellow cmdlets Import-CsConferenceDirectory, Merge-CsLegacyTopology, and Move-CsLegacyUser, Import-CsLegacyConfiguration provides a way for you to run both Microsoft Lync Server 2010 and Office Communications Server 2007 (or 2007 R2) at the same time. (And then, ideally, you would use these cmdlets to help you move everyone off Office Communications Server and onto Lync Server.) The Import-CsLegacyConfiguration cmdlet is used to import the following items from Office Communications Server to Lync Server:
· Voice policies
· Location profiles and dial plans
· Voice routes
· Voice normalization rules
· Meeting policies
· External access policies
· Archiving policies
· Presence policies
· Communicator Web Access URL settings
· Dial-in conferencing access numbers
When you run Import-CsLegacyConfiguration the first time, the cmdlet makes a copy of all the items listed above and creates corresponding items in Lync Server 2010. For example, if you had 5 voice policies in Office Communications Server, you’ll now have 5 corresponding voice policies in Lync Server.
In other words, after you run Import-CsLegacyConfiguration the first time, the relevant policies and settings in Lync Server 2010 will now be identical to the policies and settings in Office Communications Server (or as close to identical as possible). However, these policies and settings will not automatically remain in synch: if you change a voice policy in Office Communications Server that change will not be automatically made to the corresponding voice policy in Lync Server. (Yes, that would be cool. But it doesn’t work that way.) Instead, any time you make a change to an Office Communications Server policy or setting you’ll need to rerun Import-CsLegacyConfiguration. Is there anything special you should know about that? Well, now that you mention it, there are three things you should know about that:
1. If you’ve created a new item (e.g., a new voice policy) then all you have to do is run Import-CsLegacyConfiguration. The cmdlet will identify the new item and create a corresponding item in Lync Server.
2. If you’ve modified an existing item in Office Communications Server, then you must use the ReplaceExisting parameter when running Import-CsLegacyConfiguration:
What the ReplaceExisting parameter does is tell Import-CsLegacyConfiguration to replace any existing items in Lync Server with their Office Communications Server equivalent. For example, suppose you have voice policy A in both Office Communications Server and Lync Server. If you run Import-CsLegacyConfiguration without the ReplaceExisting parameter, then the cmdlet will see that you have voice policy A in both places and will do nothing whatsoever; Import-CsLegacyConfiguration doesn’t look to see if policies and settings have been modified. When you tack on the ReplaceExisting parameter, then Import-CsLegacyConfiguration will take Voice Policy A from Office Communications Server and overwrite Lync Server’s corresponding copy of voice policy A.
See how that works?
3. If you delete a policy from Office Communications Server, well, in that case Import-CsLegacyConfiguration won’t really help you: the cmdlet will not delete items from Lync Server. Instead, you’ll need to manually delete that item from Lync Server. How do you do that? Well, Windows PowerShell is one way:
Remove-CsVoicePolicy –Identity “A”
And here’s something else to keep in mind. Before you can run Import-CsLegacyConfiguration, you’ll need to install the Windows Management Instrumentation (WMI) Backward Compatibility interfaces package (you can do this by running OCSWMIBC.msi). Why do you need to do this? Well, the Import-CsLegacyConfiguration cmdlet uses WMI to read legacy data from the earlier version of Office Communications Server; Import-CsLegacyConfiguration then takes the retrieved data and creates corresponding objects in Lync Server. That’s great except that, by the default, the WMI classes required to do this aren’t installed with Lync Server. The Backward Compatibility interfaces package installs just enough WMI to let you run the migration/coexistence cmdlets.
Oh, and, after installing the Compatibility interfaces package, you should run Merge-CsLegacyTopology. When Merge-CsLegacyTopology finishes, you should next publish the merged topology by using Topology Builder. And then, after publishing the merged topology, you can finally call Import-CsLegacyConfiguration for the first time.
That’s really all there is to say about the Import-CsLegacyConfiguration cmdlet, which means that the author of today’s haiku has achieved his goal: he’s written a haiku about the Import-CsLegacyConfiguration cmdlet. His next goal? During an upcoming trip to Utah, he and his wife are planning to climb a 10,400 foot mountain. We’ll keep you posted, and we’ll see you tomorrow.