Error returned while installing webcomponents.msi lync
When configuring certificates for a lync environment, I noticed that I made a typo. Failing to correct the problem via the topology builder, I had to uninstall the lync software. After correcting my typo, the installation failed to install. This was the error I got:. After doing some digging I noticed also an event in the eventviewer:. Opening the log file as mentioned in the event, it turned out I had something to do with an duplicate entry in the applicationhost.
As stated in the error it had something to do with a duplicate entry at line Opening the applicationhost. Pingback: Error returned while installing WebComponents. You are commenting using your WordPress. You are commenting using your Google account. Additionally it can be helpful to have access to the SQL Express database management tools on the local server.
Normally this is not needed but can be used for following some of the validation steps throughout these articles. Add any additional desired SIP domains at this point , but a single SIP domain is sufficient for most deployments as well as this series of articles. Upon completion the Topology Builder window should refresh and the defined settings will be populated as shown.
The final process is to publish the changes made to the topology into the Central Management Server database which also updates information in the RTC services container in Active Directory and sets up the folder structure and permissions on the file share.
To validate and understand the changes the Topology Builder has applied to Active Directory there are a number of places to look throughout the various results logs, within Active Directory, and the SQL databases themselves.
This approach also allows for redundancy and availability features which were lacking in previous versions of OCS. As the Administrative Tools have already been installed on the server then the Lync Server Deployment Wizard can be found in the Start Menu on the local server. The Lync Server installation media is no longer required as the installation files have been copied to the server in the following default directory. Reviewing the results in the execution window should confirm that the second SQL Express instance of RtcLocal was installed as well as the core Lync Server components.
Checking prerequisite PowerShell…prerequisite satisfied. Checking prerequisite WindowsIdentityFoundation…prerequisite satisfied. Checking prerequisite SqlNativeClient…prerequisite satisfied. Checking prerequisite SqlClrTypes…prerequisite satisfied. Checking prerequisite SqlSharedManagementObjects…prerequisite satisfied.
Checking prerequisite UcmaRedist…prerequisite satisfied. Installing OcsCore. Secondly the Local CMS replica was instantiated by importing the configuration from the existing CMS database an then replicating the database data itself.
An additional step is performed here which is new to Lync the automatic replication of certificates to the CMS. Although no certificates have been installed yet for this deployment had there been one then this action would have replicated any existing OAuth certificates required for server to server MTLS communications in Lync Server Once again the Bootstrapper application will execute and perform a prerequisite check before installing additional components.
Immediately following will be the installation of the Lync server components which make up the different services and roles on the Front End server e. Installing OcsMcu. During the WebComponents installation a number of features will be installed which are the different virtual web directories and application pools in IIS. Installing WebComponents. To confirm the installation and configuration of the various web services launch Internet Information Services Manager inetmgr.
Then select the Application Pools object to view the various Lync web services which were installed for both the internal and external web sites. Also check the installed services by running the Services control panel applet services.
They will not yet be running as server certificates must be imported first, which is the next step in the deployment. To review exactly what SQL instances were installed and their roles the Microsoft SQL Server Management Studio if installed as covered in the previous article can be used to view each instance and database.
Returning to the server deployment process the next step is to request and assign server certificates so that the Lync services can be started.
Skipped as the current Administrator account has sufficient permissions to perform this action. The following names will be automatically populated for the subject name and subject alternative name. Skipped as no additional SIP domains are configured in the topology so there are none to add to the certificate request.
Completing the process will execute the Request-CsCertificate cmdlet with the provided configuration information, performing an online certificate request against the CA and then automatically importing the issued certificate into the Local Computer store. The following results were snipped down to just the important items. Create a certificate request based on Lync Server configuration for this computer.
No changes were made to the Central Management Store. At this point the main Certificate Wizard window should reflect the new status by adding a green check mark to the Default certificate and its usages. Since this is the first Lync server in the topology then an additional shared certificate needs to be created for use with a new open authentication standard called OAuth. This certificate will be used for server-to-server communications between Lync servers in addition to other products which support OAuth like Exchange Server and Office Web Apps Server.
The main difference between the two certificate requests is that the creation of the OAuth certificate also triggers a database replication task as this certificate is automatically replicated to all Lync Servers in the topology. To review the new certificates on the server use either the Certificates snap-in available in the Microsoft Management Console mmc.
To verify that all services have started successfully click Run on the Service Status Optional step to launch the Services control panel applet. Depending on how soon after the previous step this is performed one or more of the services may still be in a stopped or starting state.
Note that the Lync Server Audio Test Service will typically not be running as this service will routinely start and stop itself. If the Lync Server Front-End service or any other prerequisite service is still reported as starting then check the server CPU in Task Manager as it may still be fully tasked with all of the first-time processes performed after a fresh server installation.
Since this deployment is using a Standard Edition server then the required server host record e. But a number of additional DNS records need to be manually created to match the various Autodiscover and Simple URLs which were defined in the topology in the previous article.
The Simple URLs dialin, meet, admin were manually created in the previous article after publishing the topology so all that remains to be created are the Automatic Client Sign-In and Autodiscover records. It is important to understand the different between the legacy Automatic Client Sign-In process and the newer Lync Autodiscover approach as these are two completely different solutions.
In the legacy scenario OCS and Lync clients locate their SIP registrar directly by looking for one or more predefined hostnames e. Yet in the newer Autodiscover scenario Lync clients are programmed to first look for a different set of predefined hostnames e. But these names will instead direct the client to a web service which will in turn respond back to the client with the appropriate SIP registrar URL.
So in the first case the clients are attempting to locate a SIP registrar directly , where as in the second and more flexible solution they are attempting to locate a service which will tell them where to find their SIP registrar. This advancement in Lync provides for additional flexibility not previously made available, most notably the ability to support distributed Access Edge registrations in enterprise networks with multiple Edge pools. To review the new certificates on the server use either the Certificates snap-in available in the Microsoft Management Console mmc.
Start services for the Lync Server computer "lync. To verify that all services have started successfully click Run on the Service Status Optional step to launch the Services control panel applet. Depending on how soon after the previous step this is performed one or more of the services may still be in a stopped or starting state.
Note that the Lync Server Audio Test Service will typically not be running as this service will routinely start and stop itself.
If the Lync Server Front-End service or any other prerequisite service is still reported as starting then check the server CPU in Task Manager as it may still be fully tasked with all of the first-time processes performed after a fresh server installation. Since this deployment is using a Standard Edition server then the required server host record e. But a number of additional DNS records need to be manually created to match the various Autodiscover and Simple URLs which were defined in the topology in the previous article.
The Simple URLs dialin, meet, admin were manually created in the previous article after publishing the topology so all that remains to be created are the Automatic Client Sign-In and Autodiscover records. It is important to understand the different between the legacy Automatic Client Sign-In process and the newer Lync Autodiscover approach as these are two completely different solutions.
In the legacy scenario OCS and Lync clients locate their SIP registrar directly by looking for one or more predefined hostnames e. Yet in the newer Autodiscover scenario Lync clients are programmed to first look for a different set of predefined hostnames e. But these names will instead direct the client to a web service which will in turn respond back to the client with the appropriate SIP registrar URL.
So in the first case the clients are attempting to locate a SIP registrar directly , where as in the second and more flexible solution they are attempting to locate a service which will tell them where to find their SIP registrar.
This advancement in Lync provides for additional flexibility not previously made available, most notably the ability to support distributed Access Edge registrations in enterprise networks with multiple Edge pools.
This section is only required if any legacy clients will be used with the environment e. Lync All Lync clients will leverage the newer Autodiscover process, although some clients still support this legacy mode as a fall-back. But some Lync clients primarily the mobility clients do not support a CNAME record which points to a Host record in a different domain namespace, so in the topology used in this series of articles it would be poor practice to create an alias in the SIP domain namespace e.
Only the Lyncdiscoverinternal entry should be created on internal DNS zones as Lyncdiscover is used by external clients and thus should be reserved for external DNS zones which will be addressed in a later article.
If all has gone according to plan then the environment now includes a functional Lync Front End server which is ready for additional configuration and client testing. About Jeff Schertz Site Administrator. Hi master Schertz. Fantastic so far, Jeff. Suggestion: turn this into a "Lync CU1" deployment series with a final post on updating to CU1 — there were definitely a few quirks with that process that I felt were poorly documented by our friends in Redmond!
Hey Jeff, good write up once again. I believe Lync client now uses Autodiscover as well. If you can send me that doc in technet that would be useful. I will need that for my current design and I must have over looked that tidbit. Thx man! Interesting, as when testing a Lync Windows client with CU7. I'll have to dig into this more.
Awesome thanks. Let me know what you find on I got another one for you regarding mobility. In my testing and latest deployment, internal stays internal. The XML document returns both internal and external webservices. Have you discovered the same? That statement from TechNet doens't sound right to me either, even pre-CU1.
Thus the correct configuration of DNS records is key to routing the traffic to the desired server. Jeff your Part 1 was easy to follow. I cannot publish my topology. I added the domain admin to the groups you wanted me to and I still cannot publish I get the following. This operation might require other privileges. ConnectSqlServer at Microsoft. Make sure that you are running Topology Builder as an administrator in the event you are using any account other than the built-in Administrator user account.
Hope the Edge part comes. I has installed Edge with old step. So far so good now. But not testing yet,hope all ok,. Using a Lync Edge server should be fine with Front End servers still in place. Not sure I'm posting an article on Edge Server deployment yet, it's basically identical to so I'm not sure there is a lot of value in rehashing that here. Lync front end and Lync Edge server? I am planning to put this in production.
No, I have not tested that but my initial thought is that it should be fine. Typically the Edge server is upgraded last, but it is not a requirement in Trying to get Lync for Mac Office to work with new deployment of Lync Keep receiving error on client "Sign in to Microsoft Lync failed because the service is not available or you may not be connected to the internet" cant find logs in Mountain Lion with current documentation.
We are a Microsoft shop and don't typically deal with issues of this sort. Works fine with user on windows 7 and 8 with Lync Client. Any help or if this is even possible. Figured it out. I have a lab setup and we are looking to setup the edge server lync I only am using a single edge server and have only 1 FE server.
So my questions are.. Do I need to do any load balancing since there is only 1 edge server and 1 front end pool? My ASA firewall does not support DNS load balancing so am I forced to do HW load balancing, and if so back to question 1 what is the need for load balancing if I only have 1 edge and front end server.
Do you have to have 2 NICs on an edge server? When there is a single server in a pool then no load balancing is required. And yes, the Edge serve must have separate internal and external interfaces. Hi jeff, I am testing my Lync mobile client and I want to know if I need an edge server for Lync Mobile services. Thanks in advance. I don't know if anyone has tested the actual behavior without, but I would doubt even P2P calls between mobile clients on the same network would function.
The Edge server is required for all external media scenarios and not having one in the deployment would most likely prevent external clients from even attempting to negotiate media. In scenarios where media would need to traverse firewalls and address translation there is no possible way that could work. Hi Jeff, I have migrated Lync from to and one day all of a sudden my edge is no longer replicating with Front end.
Could you please tell me where to start? Some ppl told me it might be related to firewall rules but I have disabled firewall internally. Topology data replication is over the same port in Lync as it was in push from Front End to Edge over Create article! Have you covered any on using exchange for voice mail for Lync I'm trying to get it to work but having a few issues.
Do I need an edge server to be able to login to lync when im out of office or can I just open the ports to the standard edition server? For a supported external user scenario: yes. If you've replaced your certificate authority then you would need to reissue all certificates, but if the CA is still available and no certificates were revoked then you don't have to.
It would be recommended to update them all in most cases, if you can. Hi Jeff, any word on part 3? Thanks for your hard work! Michael, Part 3 is about halfway complete but I probably won't have it posted until after TechEd. I am puzzled by all the different and partially misleading info about LYNC certs that are required.
Sip name ABC. I plan on requesting separate single name certs for EDGE. HELP Please!!! In most cases you should be requesting a single certificate for the Front End server and two certificates for the Edge Server internal and external facing.
The reverse Proxy depends on the configuration but typically all FQDNs can be placed in the same certificate and used across multiple listeners if needed. The names depend on your configuration but the Certificate Wizard should get you most of the way there. According to my situation, my edge server have 2 NICs, and they are in same subnet. Do I need to buy public certificate for example- from godaddy to my edge and front ends?
Without public cert, is it possible to access to my edge server from mobile phone? I've deployed my servers with domain. But to access to lync from my mobile externally with 3G or WiFi , I need public domain like domain. Do I need get write sip. Placing both interfaces in the same subnet is not recommended and is unsupported by Microsoft.
The Edge Server should be using public certificates on the external interface, and internal certificates on the internal interface. You can use either on the Front End server depending on the overall configuration and requirements you have. My case is for testing purpose only. It's works in internal domain joined pc's. But can't connect external pcs and mobiles. It says : The website cannot be found. For my labs I periodically just export my Hyper-V guests to another disk to grab a point-in-time snapshot of the entire environment.
Or which type of DNS entry I have to use? The official TechNet documentation also covers this.
0コメント