MeetingPlace Express to MeetingPlace 8 Migration Issues

[Mark H]

Hey everyone,

Been testing a MeetingPlace Express (MPX) to MeetingPlace 8 (MP8) migration for yonks in our test lab and has worked flawlessly, but now that we've done it in production Murphy's Law has kicked in and we've come across a couple of good ones. Hopefully someone here might be able to give a few pointers.

• All participants entering a migrated meeting, receive a "There is not enough space to record your name" when they should be being prompted to record a name. The only work around I have is to cancel the meeting and recreate it, after that the issue is gone.
  
• Calling from a phone such as a mobile that has caller ID turned off causes issues. After entering in the meeting ID they are told to press 0 for assistance, instead of joining the meeting. If you enable caller ID from the same phone, it suddenly works perfectly.
  
• We're using the MP web node (not the WebEx node) for scheduling, but if a user selects the 'remember me' option when logging in, they will continiously be told their session has timed out and need to sign out. It works fine without selecting that options and occurs for multiple browsers etc. We are using cname DNS records to direct people to the right server (i.e. there is a cname pointing meetingplace to mp04 so that way users just enter http://meetingplace/, but the issue does occur too when using http://mp04
  

Hopefully someone herehas some ideas or pointers!

Thanks.

[anmarti2 · Accepted solution]

Hello Mark,

Very importantly make sure you have run the MeetingPlace 8.0 Patch for MPE Migration patch. Here are the instructions to download and run this:

http://docwiki.cisco.com/wiki/Cisco_Unified_MeetingPlace_Release_8.0_--_Migrating_to_Cisco_Unified_MeetingPlace_Release_8.0_from_Cisco_Unified_MeetingPlace_Release_6.0_or_from_Cisco_Unified_MeetingPlace_Express#Installing_the_Cisco_Unified_MeetingPla...

• This issue is hopefully addressed with the patch. However, as it is unlikely you are actually running out of diskspace on a new install (you can verify this by using the command "df -h"), this issue would be caused by a folder and file permissions issue. SSH into the Application Server and get the output of the command "ls -lR /mpx-record/". Here you will see a list of folders with labels similar to "006234" where "6234" will be the unique conference ID. If you compare the permissions and owners/groups of the folders and files of the meetings that were migrated to the meetings scheduled after the migration, you should see the difference. If you are handy with Linux, you can change these folder and file permissions of the migrated meetings to be the same as the folder and file permissions as the newly scheduled meetings using the commands "chmod" and "chown". If you uncomfortable in making these changes, I would have a TAC case opened.

          The folder permissions should look like this:

          drwxrwxr-x  2 mpxadmin mpx 4096 Aug  5 11:14 009798

          The file permissions should look like this:

          -rw-rw-r--  1 mpxadmin mpx 402 Aug  5 11:14 conf_10486

• This may be the result of the meetings being scheduled with the "Who can attend" set to either MeetingPlace Profile Users or Invited Profile Users with the Auto-attend/Auto-login feature enabled on the profiles. If the caller ID/ANI of the phone does not reach MeetingPlace, then MeetingPlace cannot automatically authenticate the user using the Auto-attend/Auto-login feature since this is based off the call's ANI. Otherwise with a meeting set with "Who can attend" to Anyone, dialing in and joining with no Caller ID or ANI, I cannot reproduce this issue.

• This may be an issue with a conflicting cookie as an Internet browser cookie is used when the "Remember Me" option is used. Try clearing the temporary internet files, cookies and cache and trying again. Also, check the time and date on the web server to see if it is correct.

Hope this helps,

Andrew

[Mark H]

Hi Andrew,

Thank you for the great response!

• You're right, the permissions are incorrect but both the migration patch and SR1 patch have been applied. I'll look at running the migration patch again or I'll get a TAC case opened for the permissions to be modified. Thanks.
  

• The second issue is a tricky one and currently got a TAC case for it. By default we have auto-attend disabled and meetings set that anyone can attend. It appears in some cases according to cptrace that DTMF isn't being recognised/passed, it just happens I can recreate the issue by disabling caller ID and to top it off, it only occurs when going via some of our gateways running the 15 IOS, not version 12.
  

We've been able to work around this issue however by requiring an MTP being used for the SIP trunk, so it's no longer an issue but something we're trying to understand with TAC's help.

• Have tried those suggestions, unfortunately it hasn't resolved the issue. I'm not too worried about this, I suspect it will be something we've customised in our environment and frankly we should be using integrated authentication, which I know works flawlessly and will just use this as another reason for it.
  

Thanks again for your help Andrew.