For those of you out there thinking about making your user's dreams come true with CUCiMOC, have a quick think about the following before you continue:
You are going to have to deploy a client to all of your workstations. Before you decide to do this, have a quick chat to your Systems Management guys. Depending on your environment, this may not happen as quickly or as easily as you think.
Many CUCM deployments have required a second implementation of Active Directory, due to AD admins refusing to put the required schema changes in the production environment. What does this mean for you? CUCiMOC uses the currently logged on users creds to access many services, such as retrieving voice mail. This means your user name and password must be the same in both domains. No problem right, just manually sync them. This will work, but what happens after 30 days when your password expires?
Check your dial plans... CUCiMOC will just dial the numbers you give it. One problem you may come across is that in your GAL, your numbers are probably in E164 format. Without modifications to your dial plan CUCiMOC won't be able to dial these numbers forcing you to manually modify numbers everytime you make a call.
It is not free. Depending on how you are licensed with Cisco will depend on how much this is going to cost you. Better do the maths up front.
Do you really want to strip your OCS deployment down to being just a presence engine? To make life less confusing for your users, Cisco suggests that you hide all the native functionality of Communicator, leaving only the CUCiMOC calling controls exposed. Not sure this is really what you would have intended when you started on your OCS journey.
So for Matt's 5 cents:
CUCiMOC may be a good option for people who want to start using their PC as their voice endpoint but don't want to use Microsoft's UC platform yet. If you really think this is your only/best option, I would really suggest doing a pilot production with a handful of "real" users before jumping in, as some of these issues seriously impact user experience. For those who are unsure of how Microsoft's offering will compare, why not pilot that too, you may be pleasantly surprised.
Monday, November 30, 2009
Cisco vs Microsoft. Who is telling the truth?
Over the last few days I have been listening to a lot of Cisco guys fresh from Networkers and sprouting all the latest anti-Microsoft propaganda. Here are some of the things that were given as ammunition to their followers.
1. The codecs used by Communicator are negotiated by the clients, unlike in the Cisco world, the codec is controlled by CUCM.
This is this is as the codec used by Communicator is adaptive, based on the amount of bandwidth between the clients. Obviously the OCS server is in no position to dictate this.
2. Integrating OCS with your Call Manager means you have to manage 2 dial plans, so keep it simple by using CUCiMOC.
In my experience it is easier to write up a dial plan in OCS than it is to deploy a client to thousands of machines. The one good thing about CUCiMOC, is that it does atleast start people getting used to using their PC as their Voice end point.
3. OCS has no CAC
I am not sure if I have ever picked up the phone and heard fast busy tone because my call was blocked by CAC. I think these days we have more issues with email clogging up links than we do voice. In any environment with or without CAC, if the network is not provisioned correctly you are going to have problems with everything you do not just voice.
4. Calls in a branch office will hair pin through Mediation Server
This scenario describes a situation where in a branch office, calls between Office Communicator and a Cisco phone will have to go from Communicator across the WAN to the Mediation Server and back down to the Cisco phone. This is true and would happen in an R2 environment (I have heard rumours that this will go away in 2010). I would however say that if you are migrating your voice platform to OCS that planning is key, and you would either have to migrate all or none in this situation.
5. Unity provides a richer user experience than Exchange 2007
The first problem with this statement is that Unity is built on Exchange (and not even the latest version). The issue most companies have with Unity is that it requires a schema extension. I have not yet seen a company that has put the Cisco schema extension into their production AD. So most implementations involve creating a second AD just for Telephony, giving them the flexibility they need to get the job done. This in turn means that users will now have 2 mailboxes. 1 for email and maybe fax/SMS and the other for voice mail. This means that you can only get real UM with a few paddle pop sticks and some sticky tape.
6. Microsoft UM requires a 3rd party for MWI
While this was true with Exchange 2007, this problem has now gone away. Exchange 2010 can natively switch that oh so important little red light on and off.
So for Matt's 5 Cents:
Both Cisco and Microsoft have great features and both have room for improvement. When looking at deploying UC, it is important to look holistically at the experience you are providing to your users, and keep your eyes on the road maps of your favourite vendors. This space is fast paced and ever-changing. Most importantly, to quote a hip hop group from the 90's, "Don't believe the hype".
1. The codecs used by Communicator are negotiated by the clients, unlike in the Cisco world, the codec is controlled by CUCM.
This is this is as the codec used by Communicator is adaptive, based on the amount of bandwidth between the clients. Obviously the OCS server is in no position to dictate this.
2. Integrating OCS with your Call Manager means you have to manage 2 dial plans, so keep it simple by using CUCiMOC.
In my experience it is easier to write up a dial plan in OCS than it is to deploy a client to thousands of machines. The one good thing about CUCiMOC, is that it does atleast start people getting used to using their PC as their Voice end point.
3. OCS has no CAC
I am not sure if I have ever picked up the phone and heard fast busy tone because my call was blocked by CAC. I think these days we have more issues with email clogging up links than we do voice. In any environment with or without CAC, if the network is not provisioned correctly you are going to have problems with everything you do not just voice.
4. Calls in a branch office will hair pin through Mediation Server
This scenario describes a situation where in a branch office, calls between Office Communicator and a Cisco phone will have to go from Communicator across the WAN to the Mediation Server and back down to the Cisco phone. This is true and would happen in an R2 environment (I have heard rumours that this will go away in 2010). I would however say that if you are migrating your voice platform to OCS that planning is key, and you would either have to migrate all or none in this situation.
5. Unity provides a richer user experience than Exchange 2007
The first problem with this statement is that Unity is built on Exchange (and not even the latest version). The issue most companies have with Unity is that it requires a schema extension. I have not yet seen a company that has put the Cisco schema extension into their production AD. So most implementations involve creating a second AD just for Telephony, giving them the flexibility they need to get the job done. This in turn means that users will now have 2 mailboxes. 1 for email and maybe fax/SMS and the other for voice mail. This means that you can only get real UM with a few paddle pop sticks and some sticky tape.
6. Microsoft UM requires a 3rd party for MWI
While this was true with Exchange 2007, this problem has now gone away. Exchange 2010 can natively switch that oh so important little red light on and off.
So for Matt's 5 Cents:
Both Cisco and Microsoft have great features and both have room for improvement. When looking at deploying UC, it is important to look holistically at the experience you are providing to your users, and keep your eyes on the road maps of your favourite vendors. This space is fast paced and ever-changing. Most importantly, to quote a hip hop group from the 90's, "Don't believe the hype".
Monday, November 9, 2009
Ever find patching your OCS Servers painful? Relief is on the way...
If you are like me and have all too often wasted precious time working out what patches you need to drop onto your OCS 2007 R2 servers, I have great news for you. Microsoft have just released the Office Communications Server 2007 R2 Cumulative Update Installer. This package will determine what packages you need to install, list them out with links to the KBs, download them for you and install them in the correct order. This will save you hours.
So how does one get their hands on this little beauty you ask? Just pop over to http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=b3b02475-150c-41fa-844a-c10a517040f4 and simply download the ServerUpdateInstaller package.
Once you run the Cumulative Update Installer, you will see a list of the updates that are needed for the particular server you are patching.
After clicking the Install Updates button, the required updates will be automatically downloaded and installed.
As the patches are installed the progress is updated, and a log is created for each update. One thing I love is that once all the patches are installed and you click the Close button, the update packages that were downloaded are automatically cleaned up.
One important note is that you will still need to manually load Group Chat patches and the Database upgrade (OCS2009-DBUpgrade.msi).
If you want to automate things further you also have the option of running the updater with the /silent/forcereboot switch which will install the updates silently and then reboot your server once finished. You can also have the needed updates downloaded for you and placed in a subfolder named Extracted by using the /extractall switch.
So for Matt's 5 cents:
Don't waste your time guessing what updates you need to load on each of your R2 servers, just reach for the Cumulative Update Installer, kick back and watch it do its magic.
So how does one get their hands on this little beauty you ask? Just pop over to http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=b3b02475-150c-41fa-844a-c10a517040f4 and simply download the ServerUpdateInstaller package.
Once you run the Cumulative Update Installer, you will see a list of the updates that are needed for the particular server you are patching.
After clicking the Install Updates button, the required updates will be automatically downloaded and installed.
As the patches are installed the progress is updated, and a log is created for each update. One thing I love is that once all the patches are installed and you click the Close button, the update packages that were downloaded are automatically cleaned up.
One important note is that you will still need to manually load Group Chat patches and the Database upgrade (OCS2009-DBUpgrade.msi).
If you want to automate things further you also have the option of running the updater with the /silent/forcereboot switch which will install the updates silently and then reboot your server once finished. You can also have the needed updates downloaded for you and placed in a subfolder named Extracted by using the /extractall switch.
So for Matt's 5 cents:
Don't waste your time guessing what updates you need to load on each of your R2 servers, just reach for the Cumulative Update Installer, kick back and watch it do its magic.
Saturday, November 7, 2009
To migrate the Global Settings or not to, that is the question...
So we are about to load the R2 schema and the inevitable question "Should we move the Global Settings Container?" came up. In my previous company we had one massive domain and so there was no value in moving it. Every DC had the settings so no problem. In my new customer's environment they have a multi-domain forest and only 3 DCs in the Root domain. We could have left it but ultimately decided it would be best to move it.
I have to say I was half expecting this to go pear shaped. We had no test environment and therefore couldn't say hand on heart that everything would all be ok come Saturday morning. I tried to find some incense and a virgin to sacrifice to the gods but failed miserably so I decided it would be easier to run through the process in my own lab to get more familiar.
For those of you who are not familiar with this process it is basically as follows:
So for Matt's 5 cents:
If you have a single domain just leave it. Moving to the Config container won't add any value and at the moment it is just a recommendation from Microsoft. If they make it mandatory to move it in the future, I am sure/I hope, they will build a better tool as I am not sure that I would want to go through this in a domain with hundreds of thousands of user objects.
If you have multiple domains but all your servers are in the root domain, again you probably won't gain anything by moving things around.
If you have servers in multiple domains, or you only have a few DCs in the Root Domain, then you should consider moving to the Config Container.
Whatever you decide, don't be afraid, after all we did it and survived.
I have to say I was half expecting this to go pear shaped. We had no test environment and therefore couldn't say hand on heart that everything would all be ok come Saturday morning. I tried to find some incense and a virgin to sacrifice to the gods but failed miserably so I decided it would be easier to run through the process in my own lab to get more familiar.
- Download the Global Settings Migration Tool from http://go.microsoft.com/fwlink/?LinkId=137424 and extract it.
- Stop all the OCS services on all of your servers.
- With an account that is a member of Domain Admins or Enterprise Admins, Run cscript MigrateOcsGlobalSettings.vbs /Action:MigrateGlobalSettingsTree and wait for this to replicate. This copies the Global Settings Tree Structure to the Configuration container.
- Still with the same account run cscript MigrateOcsGlobalSettings.vbs /Action:MigrateGlobalSettingsProperties and again wait for replication. This will copy the Global Settings Attributes over to the new tree.
- You now need to set the correct permissions by running Forest Prep with the OCS R1 version of Lcscmd. run LcsCmd /Forest /Action:ForestPrep /global:configuration and again wait for replication to occur.
- Now for the fun parts, to update the DN References of all your server objects run cscript MigrateOcsGlobalSettings.vbs /Action: MigrateServerDnReferences /SearchBaseDN:dc=mydomainthathasmyservers,dc=com. If you have deployed servers in multiple domains you must run this for each one. You may have to run this multiple times until it returns "completed successfully". Once this change has replicated to the domains that hold your users you can continue.
- This is probably the most time consuming part depending on how many users you have. Run cscript MigrateOcsGlobalSettings.vbs /Action: MigrateUserDnReferences /SearchBaseDN:dc=domainwithmyusers,dc=com. Now this is the part of the script that I didn't like, we had only 3000 activated users in a domain that had about 30000. We had to run this tool for each domain that had users and we had to run it 5 or 6 times until it completed successfully.The good thing is that is doesn't traul through all the users, it only targets activated users, so if you have a big domain but only a few users it will only a little while.
- Once this is all complete you can remove the Global Settings Tree from the System Container by running cscript MigrateOcsGlobalSettings.vbs /Action: DeleteSystemGlobalSettingsTree.
- Restart the OCS services or even reboot for fun and you are done.
If you have a single domain just leave it. Moving to the Config container won't add any value and at the moment it is just a recommendation from Microsoft. If they make it mandatory to move it in the future, I am sure/I hope, they will build a better tool as I am not sure that I would want to go through this in a domain with hundreds of thousands of user objects.
Whatever you decide, don't be afraid, after all we did it and survived.
Wednesday, November 4, 2009
Not a good start to the week
I have just started working with a new customer and my first assignment was to help feed and water their existing OCS R1 environment.
On Friday night I left the office with only one thing on my mind, how to avoid Trick or Treaters. The weekend passed all too quickly and I arrived on Monday morning with queries left, right and center from people that couldn't log into Communicator. Unbeknownst to me, my customer's service provider (who by the way doesn't manage the OCS environment) decided to do some patching over the weekend. This was great other than the fact that they had loaded KB974571 (http://support.microsoft.com/kb/974571) which, as we know will basically kill your OCS R1 boxes.
Thankfully there was plenty of noise around this issue and even though I hadn't had my morning coffee, I was able to quickly work out what had happened. I ran the fix available @ http://go.microsoft.com/fwlink/?LinkId=168248 , I was able to start the OCS Services and all was well again in the world. I even managed to appear like I was doing some work :-p
So for Matt's 5 cents:
As this fix is able to be run before or after KB974571 is loaded, I recommend going ahead and loading it now as your Wintel guys might be more enthusiastic than you think.
On Friday night I left the office with only one thing on my mind, how to avoid Trick or Treaters. The weekend passed all too quickly and I arrived on Monday morning with queries left, right and center from people that couldn't log into Communicator. Unbeknownst to me, my customer's service provider (who by the way doesn't manage the OCS environment) decided to do some patching over the weekend. This was great other than the fact that they had loaded KB974571 (http://support.microsoft.com/kb/974571) which, as we know will basically kill your OCS R1 boxes.
Thankfully there was plenty of noise around this issue and even though I hadn't had my morning coffee, I was able to quickly work out what had happened. I ran the fix available @ http://go.microsoft.com/fwlink/?LinkId=168248 , I was able to start the OCS Services and all was well again in the world. I even managed to appear like I was doing some work :-p
So for Matt's 5 cents:
As this fix is able to be run before or after KB974571 is loaded, I recommend going ahead and loading it now as your Wintel guys might be more enthusiastic than you think.
Subscribe to:
Posts (Atom)