A Unified Communication Blog
Get Adobe Flash player

Monthly Archives: January 2012

I was at a customer today, where they have just installed a new Exchange 2010 SP2 CAS server with the UM role also. However the “MSExchange Unified Messaging” Service would not start.

A quick look in the application event log showed the below entries:

The UM worker process (UMWorkerProcess.exe) couldn't start. More information: A file couldn't be converted for playback over the telephone: An error occurred in the Audio Compression Manager: The operation completed successfully

The UM worker process (UMWorkerProcess.exe) couldn’t start. More information: A file couldn’t be converted for playback over the telephone: An error occurred in the Audio Compression Manager: The operation completed successfully

 

The Unified Messaging worker process has terminated. The state of the UM worker process is “Init”.

 

 The Microsoft Exchange Unified Messaging service was unable to start. More information: “Microsoft.Exchange.UM.UMService.UMServiceException: The UM worker process encountered a fatal error during startup.

   at Microsoft.Exchange.UM.UMService.UMService.StartService()

   at Microsoft.Exchange.UM.UMService.UMService.OnStartInternal(String[] args)”

 

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

 

The solution to the problem was to install “Desktop Experience” on the server, and after a restart of the server, the UM service started as it should.

 

Duing an migration from OCS 2007 R2 to Lync a hunt group was deleted in OCS 2007 R2, however the sip address and uri line was still active in Lync as an offline user, as showen below.

So to remove this permanently you first need to find the sip uri for the contacts object (if you don’t know it already).

You can use this command:

Get-CsApplicationEndpoint

So to remove the old hunt group or response group you have to use the rgscot.exe utility on the OCS Server.

The utility is located in “C:Program FilesCommon FilesMicrosoft Office Communications Server 2007 R2”

RgsCot.exe /delete /primaryuri:sip:”SIP URI”

It should respond with this

The contact object for sip: ”SIP URI”  has been deleted successfully.

Then update the Lync Address book (Update-CsAddressBook) and wait awhile for it to get removed from the clients’ address book copy.

Duing an migration from OCS 2007 R2 to Lync the Dialin Conference number was removed in OCS, however it was still present in Lync.

This was showen on the Dialin Page in Lync, where the last entry is the OCS 2007 R2 number.

It’s not possible to remove or change OCS conference numbers in Lync or vice versa. The number has to be moved to Lync if it shall be handle correctly.

So to remove the old numer you have to find the SIP address for the “correct” Lync dialin number:

Get-CsDialInConferencingAccessNumber |fl

Then run this command

Set-CsDialInConferencingAccessNumber “Sip Address” –ScopeToSite

This will do the trick and the OCS number is removed in the Lync dialin page.

 

 

Last week I had trouble dialing out of Lync to the PSTN network. Incoming calls and internal Lync calls worked fine, but the outgoing calls failed with this error:

ms-diagnostics: 10407;source=”internallyncserver.contoso.com”;reason=”Gateway responded with 407 Proxy Authentication Required”;component=”MediationServer”;SipResponseText=”Not Acceptable Here”;GatewayFqdn=”siptrunkprovider.somewhereoninternet.com”

ms-diagnostics-public: 10407;reason=”Gateway responded with 407 Proxy Authentication Required”;component=”MediationServer”;SipResponseText=”Not Acceptable Here”

ms-trunking-peer: siptrunkprovider.somewhereoninternet.com;User-Agent=”OpenSer (1.1.1-notls (i386/linux))”

ms-endpoint-location-data: NetworkScope;ms-media-location-type=intranet

I’m using a Sip trunk provider, and the problem was that they authenticate me, by my outgoing IP address of the Lync mediation server. That’s not it self the problem, but the problem was that one of my colleagues changed my firewall, so I was coming from a wrong IP address, and therefore I got rejected at my sip trunk provider. So after changed the firewall so I came from the correct IP address it worked again.

After I had a bad experience the first time I was installing Service Pack 2 for Exchange 2010 (see here),  I have created a small check list before I install SP2 on an Exchange 2010 server.

Unregister Forefront with this command:

C:Program Files (x86)Microsoft Forefront Protection for Exchange Server>FSCUtility.exe /disable

Set the Powershell Execution policy to undefined with these commands:

get-executionpolicy -list

set-executionpolicy -scope localmachine -executionpolicy undefined

(See http://support.microsoft.com/kb/947821 for details about this.)

 

From Powershell install the new requriment for the IIS6 WMI Compatibility role.

Import-Module ServerManager

Add-WindowsFeature Web-WMI

Restart the server.

Install SP2, and reboot the server again when it is finished.

Register the forefront again with this command:

C:Program Files (x86)Microsoft Forefront Protection for Exchange Server>FSCUtility.exe /enable

Set the Powershell execution policy back:

set-executionpolicy -scope localmachine -executionpolicy Unrestricted

 

If you are installing the service pack on a DAG cluster, then make sure to set the server in maintenance mode with the StartDagServerMaintenance.ps1 script. See this great blog entry from Tony Redmond http://thoughtsofanidlemind.wordpress.com/2011/12/05/installing-exchange-2010-sp2/

 

 

Before Christmas I was installing SP2 on a customer’s Exchange 2010 server, and that gave me a lot of problems.

During the process of installing the service pack it completed the prerequisite checks and started the install just fine.

One of the first thing the service pack is doing, is to delete all the old Exchange files, before it installs the new ones.

However after the files where deleted the installer failed with the below error:

[12-12-2011 09:12:15.0876] [1] 0.  ErrorRecord: AuthorizationManager check failed.

[12-12-2011 09:12:15.0876] [1] 0.  ErrorRecord: System.Management.Automation.PSSecurityException: AuthorizationManager check failed.

   at System.Management.Automation.AuthorizationManager.ShouldRunInternal(CommandInfo commandInfo, CommandOrigin origin, PSHost host)

   at System.Management.Automation.CommandDiscovery.ShouldRun(ExecutionContext context, PSHost host, CommandInfo commandInfo, CommandOrigin commandOrigin)

   at System.Management.Automation.CommandDiscovery.LookupCommandProcessor(CommandInfo commandInfo, CommandOrigin commandOrigin, Nullable`1 useLocalScope)

   at System.Management.Automation.CommandDiscovery.LookupCommandProcessor(String commandName, CommandOrigin commandOrigin, Nullable`1 useLocalScope)

   at System.Management.Automation.ExecutionContext.CreateCommand(String command)

   at System.Management.Automation.CommandNode.CreateCommandProcessor(Int32& index, ExecutionContext context)

   at System.Management.Automation.CommandNode.AddToPipeline(PipelineProcessor pipeline, ExecutionContext context)

   at System.Management.Automation.PipelineNode.Execute(Array input, Pipe outputPipe, ArrayList& resultList, ExecutionContext context)

   at System.Management.Automation.StatementListNode.ExecuteStatement(ParseTreeNode statement, Array input, Pipe outputPipe, ArrayList& resultList, ExecutionContext context)

[12-12-2011 09:12:15.0876] [1] [ERROR] The following error was generated when “$error.Clear();

          & $RoleBinPathServiceControl.ps1 EnableServices Critical

        ” was run: “AuthorizationManager check failed.”.

[12-12-2011 09:12:15.0876] [1] [ERROR] AuthorizationManager check failed.

[12-12-2011 09:12:15.0876] [1] [ERROR-REFERENCE] Id=AllRolesMidFileCopyComponent___af0f15afe35c4e7cba121e546f405214 Component=EXCHANGE14:CurrentReleaseSharedDatacenterSetup

[12-12-2011 09:12:15.0876] [1] Setup is stopping now because of one or more critical errors.

[12-12-2011 09:12:15.0876] [1] Finished executing component tasks.

[12-12-2011 09:12:15.0922] [1] Ending processing Start-MidFileCopy

 

Ohh no… this is not good. The only choice I got, was to finish the install with the error.

Afterwards when I ran the installer again I got this error:

The previous installation path could not be found in the registry. Only disaster recovery mode is available.

The previously installed version could not be determined from the registry. Only disaster recovery mode is available.

The disasterrecovery option couldn’t fix the server.

So to fix that new problem I had to do the below:

Set execution policy in powershell to unassigned (see http://support.microsoft.com/kb/981474)

Looked at registry path HKLMsoftwareMicrosoftExchange server V14

– deleted subnode “Midfilecopy” and “Setup” nodes under V14

– Reboot the server

– Run setup.com /m:recoverserver from the SP1 install library

When I ran the recover it failed again with a new error when it configured the Client Access role – the error is the below one:

[12-12-2011 12:04:17.0585] [1] 0.  ErrorRecord: The term ‘C:Program FilesMicrosoftExchange ServerV14ScriptsConfigureNetworkProtocolParameters.ps1′ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

[12-12-2011 12:04:17.0585] [1] 0.  ErrorRecord: System.Management.Automation.CommandNotFoundException: The term ‘C:Program FilesMicrosoftExchange ServerV14ScriptsConfigureNetworkProtocolParameters.ps1′ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

   at System.Management.Automation.CommandDiscovery.LookupCommandInfo(String commandName, CommandOrigin commandOrigin)

   at System.Management.Automation.CommandDiscovery.LookupCommandProcessor(String commandName, CommandOrigin commandOrigin, Nullable`1 useLocalScope)

   at System.Management.Automation.ExecutionContext.CreateCommand(String command)

   at System.Management.Automation.CommandNode.CreateCommandProcessor(Int32& index, ExecutionContext context)

   at System.Management.Automation.CommandNode.AddToPipeline(PipelineProcessor pipeline, ExecutionContext context)

   at System.Management.Automation.PipelineNode.Execute(Array input, Pipe outputPipe, ArrayList& resultList, ExecutionContext context)

   at System.Management.Automation.StatementListNode.ExecuteStatement(ParseTreeNode statement, Array input, Pipe outputPipe, ArrayList& resultList, ExecutionContext context)

[12-12-2011 12:04:17.0585] [1] [ERROR] The following error was generated when “$error.Clear();

          . “$RoleInstallPathScriptsConfigureNetworkProtocolParameters.ps1″;

          Set-NtlmLoopbackCheck $false

        ” was run: “The term ‘C:Program FilesMicrosoftExchange ServerV14ScriptsConfigureNetworkProtocolParameters.ps1′ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.”.

[12-12-2011 12:04:17.0585] [1] [ERROR] The term ‘C:Program FilesMicrosoftExchange ServerV14ScriptsConfigureNetworkProtocolParameters.ps1′ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

[12-12-2011 12:04:17.0585] [1] 1.  ErrorRecord: The term ‘Set-NtlmLoopbackCheck’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

[12-12-2011 12:04:17.0585] [1] 1.  ErrorRecord: System.Management.Automation.CommandNotFoundException: The term ‘Set-NtlmLoopbackCheck’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

   at System.Management.Automation.CommandDiscovery.LookupCommandInfo(String commandName, CommandOrigin commandOrigin)

   at System.Management.Automation.CommandDiscovery.LookupCommandProcessor(String commandName, CommandOrigin commandOrigin, Nullable`1 useLocalScope)

   at System.Management.Automation.ExecutionContext.CreateCommand(String command)

   at System.Management.Automation.CommandNode.CreateCommandProcessor(Int32& index, ExecutionContext context)

   at System.Management.Automation.CommandNode.AddToPipeline(PipelineProcessor pipeline, ExecutionContext context)

   at System.Management.Automation.PipelineNode.Execute(Array input, Pipe outputPipe, ArrayList& resultList, ExecutionContext context)

   at System.Management.Automation.StatementListNode.ExecuteStatement(ParseTreeNode statement, Array input, Pipe outputPipe, ArrayList& resultList, ExecutionContext context)

[12-12-2011 12:04:17.0585] [1] [ERROR] The following error was generated when “$error.Clear();

          . “$RoleInstallPathScriptsConfigureNetworkProtocolParameters.ps1″;

          Set-NtlmLoopbackCheck $false

        ” was run: “The term ‘Set-NtlmLoopbackCheck’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.”.

[12-12-2011 12:04:17.0585] [1] [ERROR] The term ‘Set-NtlmLoopbackCheck’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

[12-12-2011 12:04:17.0585] [1] [ERROR-REFERENCE] Id=ClientAccessComponent___178a10624c88445093855c4ede7e9b9c Component=EXCHANGE14:CurrentReleaseSharedDatacenterSetup

 

So it seems like when doing and recovery from the SP1 directory it couldn’t find this file:

‘C:Program FilesMicrosoftExchange ServerV14ScriptsConfigureNetworkProtocolParameters.ps1

That file is not part of the SP1, but is only located in the RTM version of Exchange 2010. Even after I copied all the missing script files from the RTM version to the server, I was not able fix this. So ones again the installer failed prematurely.

So now I had an almost recovered server, but the Client Access didn’t function. So I removed the CAS role from the add/remove programs. After that I installed Service Pack 2 with succeed, and then I installed the CAS role again from the SP2 setup, and the server has been running fine since then.

 

So what caused all these problem? After I did some research, it seems like that because I have changed the execution settings in powershell to accept unsigned scripts it was, this that caused the first error.

So check this MS article: http://support.microsoft.com/kb/981474 and make sure that both user and machine polices is undefined.

 

 

Search

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 72 other subscribers

Follow me on Twitter