Exchange 2010 UM crashing all the time on GalGrammar error

Issue: Exchange 2010 UM crashing consistently with the following errors


 

Task Category:    UMCore

The Unified Messaging server shut down process umservice (PID=10627) because a fatal error occurred.

Task Category:    UMService

A fatal error occurred in the Microsoft Exchange Unified Messaging service. The Service Control Manager will restart the Unified Messaging service automatically to recover from this error.

Error details:

"Microsoft.Exchange.UM.UMService.UMServiceException: The Microsoft Exchange Unified Messaging service can't create a worker process because SIP ports ("5069″ or "5071″) are unavailable.

 

Task Category:    UMWorkerProcess

An unhandled exception occurred in a UM worker process: "Microsoft.Exchange.Diagnostics.ExAssertException: ASSERT: couldn't generate unique name!

at Microsoft.Exchange.Diagnostics.ExAssert.AssertInternal(String formatString, Object[] parameters)

at Microsoft.Exchange.UM.UMCore.GalGrammar.GenerateActivePath(CultureInfo culture, String extension)

 
After reading Lee Desmond's blog on these errors and having no luck with his recommended resolutions, I kept looking. Searching based on things in the event log, I was able to determine the issue was in the grammar generator that basically builds the speech to say everyone's name when you get their voicemail.

 
The path for this, by default is in the C:\Program Files\Microsoft\Exchange Server\v14\UnifiedMessaging\grammars folder.

 
There are several files in this folder, the most being GRXML and CFG files. The default named files of:

• Calendar.grxml
• common.grxml
• contacts.grxml
• Distributionlist.grxml
• Email.grxml
• Mainmenu.grxml

 
Should be in there, and additionally there are cfg/grxml combinations for "gal" and "distributionlist"

 
However, this is what our folder had in it (all the way to 99)

 



 

Cut/Paste these all to a "backup" directory with the UM service stopped, then restarted it, and watched the application event log until I got EventID 1132:

 

 



 
After this, the grammar directory looked a lot more normal:

 

 

Lync 2013, SQL, and low RAM situations

I recently was working with a customer with a Lync 2013 Enterprise Edition single node front end who was finding that Lync and SQL services were frequently failing and generally performing very poorly. This was a new deployment and only homed about five users at the time.
After reviewing the Front End's CPU and RAM, we saw that it had 16GB of RAM at its disposal, and there was plenty of available memory, but we would see memory errors in the event log, and even while trying to pull up the properties of the SQL server itself:



 
After stopping and starting SQL, we were able to pull up the properties and found that the SQL memory was set very low.
LYNCLOCAL:


RTCLOCAL:


Comparing these settings to known working configurations, these values were about 10-12x too small. So we upped the memory here, and the server began behaving… for some time at least. The SQL memory settings are dynamically changed by Lync, so the following day, they would revert to the above settings and performance would take a hit.
In our findings, these settings are defined as a percentage of installed memory at time of Lync deployment. In this particular case, the Lync Front End deployment was performed at a time when the virtual machine was provisioned with VERY low system memory. So the SQL setting was set in Lync, and when memory was later upgraded to prepare for deployment, the change was unknown to Lync.
The Fix

The fix here was simply to re-run the Lync Deployment Wizard Step One for the local SQL instances with the system memory at its production value. Running this reset the setting and the servers have run without a performance issue since!
In testing this more since, here is what we found the defaults to be (roughly):

Database	Min Memory	Max Memory
RTCLOCAL	12% of installed	15% of installed
LYNCLOCAL	6% of installed	8% of installed