Welcome to the second half of the Persistent Chat discussion!

We learned two things about Persistent Chat logs in the last post:

They are conversations which are accessible to other Lync users.
AND
You can add more to stored Chat logs later.

This functionality makes them very useful as an information asset.

Last time I compared chat logs to notes from a meeting. How do you use notes in your office? How would you, if you could share the notes with others & update them whenever necessary?

If you’re not sure, let me give you some ideas.

8 Uses for Persistent Chat Logs

FOR BUSINESS

• Change Log: A chat room window is great for tracking changes to software development, web design, content development and a whole lot more.
• Client Notes: We all have that 1 client who likes things done a certain way, and we need to make sure everyone knows it…
• Project Management Reference: Every project generates notes, specifications, directives, and so on. Keep them in one log and everyone has easy access.
• Team Collaboration: SharePoint Sites make a great platform for collaborating team members. But if you aren’t running SharePoint, Lync’s Persistent Chat provides a simple way to keep teams on track with what each person’s doing.

FOR ORGANIZATIONS/NONPROFITS

• Frequently Asked Questions (FAQ): As new questions come in, someone will update the FAQ log. Any good questions can be posted to the website.
• Project Coordination: A project manager can use a chat room log as the central location for project steps and goals.
• Emergency Updates: With Lync for Mobile, organizations dealing with emergencies such as the Moore Tornado can update the main office from the site. (PlanetMagpie extends every sympathy to those affected. I have personally donated to assist recovery efforts.)
• PR: Storing talking points, public relations contacts and media messaging in one place? Sounds like an easy way to keep PR consistent!

8 uses. Many of which overlap, and can extend other daily processes. Sounds even more valuable now, doesn’t it?

So how do you start using Lync’s Persistent Chat? You’ll have to create a chat room. Chat rooms are logged and updated live for all chat room members (like Skype). Here’s how to start off.

How to Create a Persistent Chat Room in Lync 2013

1. In Lync 2013, click the Chat Rooms icon between Contacts and Conversation History.
2. Click the gray plus icon on the right, above the chat room list. Its tooltip says, “Add a Room.”
3. A dropdown menu will appear. To follow (join) an existing chat room, click “Follow a Room…” We will create a new chat room here, so click “Create a Chat Room…”
4. A browser window will open. Navigate to the My Rooms page.
5. Click “Create a New Room” to open the Room Creation page.
6. Enter the details in the page fields:
1. Room Name – A name for the chat room. Keep chat room names descriptive & consistent (e.g., “Project Management Reference-UI”).
2. Check Names – Click this to make sure the name is not in use already.
3. Description – Explain your chat room’s purpose, so others will recognize it.
4. Privacy – Choose a privacy setting for your room from the options:
1. Open: Anyone can search for, read and write in the chat room.
2. Closed: Members (those who follow the chat room) can open, read and write in the room. Non-members can search for the room and see who’s a member, but nothing more. (Default)
3. Secret: Only members can see, read or write in this chat room.
5. Manager (Optional): Enter names of any managers you want for the chat room into the Managers field. Managers can add room members and change room settings. As the one who created the chat room, you’re already a manager. creators are automatically added as managers. Separate names by semicolons. When done, click the “Check Names” button to make sure Lync can recognize their identities.
6. Members: Enter names of anyone you want to have access to the chat room. (You’re automatically a member.)
7. Notifications: Do you want the new members you’ve identified to receive a notice that they’ve been added to your chat room? Then select “Inherit invitation setting from category (True).” Otherwise, select “No invitations sent to members.”

Finally, click the Create button. This will take you back to the My Rooms dialog, where you’ll see a confirmation that your new chat room is ready.

In Lync’s Chat Rooms window, you saw three options earlier: Followed, Member of, and New. Your new chat room should be listed under both Followed and Member Of. (If not, right-click the chat room name and select “Follow This Room.”)

Double-click the chat room and start typing!

You have a new chat room. Make use of it!

I hope this pair of posts will help to make businesses aware of Persistent Chat. It’s an underdog in the Lync communications family, though it’s arguably one of the most flexible tools.

Look for more Persistent Chat-related posts coming soon!

I’ll end with the same question I asked last week: Do you currently use Persistent Chat or Group Chat in Lync? What do you use it for the most?

A Lync Insider reader emailed me the other day, asking about Mobility Services. His external users couldn’t log in using Lync Mobile, and he wasn’t sure why.

After reviewing what he said, I thought it sounded similar to a problem we encountered during the Moving to Lync Server 2013 process.

The Problem: Everything’s Working, Except Mobility Services for External Users

The reader (let’s call him Bob) runs Lync Server 2010 Standard Edition. A 2010 Front End pool and a 2010 Edge Server, in place and properly configured. Voice, video, chat, mobility services, and federation all work fine.

Bob introduces a Lync Server 2013 Front End server in a new pool, in co-existence mode. Following configuration, Bob finds that just about everything is–still working fine!

Except for one thing. A Lync 2013 user, when signing in externally with Lync Mobile, experiences an error. Can’t Connect to Server. It may be busy or unavailable.

What’s going on here? Bob checks his Edge Server. DNS and push settings are configured. Internal Lync users on both Lync 2010 and Lync 2013 have no issues. External users can use voice and video.

It’s just Mobility Services which aren’t working on the Lync 2013 server. Why not?

The Solution: A 2013 Edge Server is Needed

In Part 7 of the Moving to Lync Server 2013 series, I mentioned a change we made after implementing the 2013 Edge Server:

“Larry also pointed the 2010 topology to the 2013 Edge server. External DNS must point to new Edge only. The new Edge Server (provided DNS is updated) will work for both 2013 and 2010 users.”

Here is the solution for Bob’s problem.

You do need a 2013 Edge Server to fully use Mobility Services. The new Mobility Services in 2013 is designed to take tablets into account; Lync 2010 didn’t have that functionality native. (Cumulative Updates did allow for tablet support, but it’s better-supported in Lync Server 2013.)

We encountered a Lync Mobile error similar to Bob’s while troubleshooting the 2013 Edge. Even though most of our users still used Lync 2010 clients, we moved all users from the 2010 Edge Server to the new 2013 Edge Server.

Everyone’s Lync clients worked without a hitch, irrespective of platform, after that. Including Lync Mobile.

Bob thought he’d just missed a settings tweak. He didn’t; in fact, he’d done a very thorough job on his topology. What he was missing was an additional Edge Server. With that in place, Mobility Services for Lync 2013 works!

If you’re planning to use Co-Existence Mode to transition from Lync Server 2010 to Lync Server 2013, take note. A 2013 Edge Server is critical to begin transitioning Lync users. Not to mention mobile access.

Have you encountered a mobility error like this? Let’s discuss!

The Polycom CX700 phone ships with version 7577.4100 of the Lync Phone Edition operating system. It’s an older version, from OCS days.

You can still use this phone with Lync Server 2010 and 2013, by installing the latest version of Lync Phone Edition.

However, attempting to upgrade it via the direct route fails. Turns out there’s an error in its upgrade path.

We encountered this error, and after some online research plus talking to Microsoft, came to the solution. Here it is, for your future reference!

The Problem: CX700 Won’t Allow Upgrades OR Login

Like all Polycom phones, the CX700′s OS is upgradeable. We found out about the latest version of Lync Phone Edition, Cumulative Update 7 (CU7). Hey, new version! Let’s upgrade!

Except we couldn’t. We tried logging into the phone for upgrading…and failed. The phone stalled, eventually giving us a Certificate Authentication Error.

Why would the phone resist upgrading? Were we missing a setting? Did we have the wrong process?

Time to find out. To the Internet!

The Solution: CX700 Requires CU5 Before CU7

Thanks to a call to Microsoft and one of Jeff Schertz’s excellent blog posts, we discovered the problem. It’s an error between version upgrades of Lync Phone Edition. Microsoft has not listed this error on their websites, but they will confirm the error exists if asked.

In order to upgrade to CU7, you must first install a prior update, Cumulative Update (CU5). Once CU5 is installed, the CX700 will recognize CU7 as a valid upgrade path for its OS, and the install will go through.

Jeff Schertz, a Lync Server MVP and blogger at http://Blog.Schertz.Name, has posted an explanation and workaround for the CU5-to-CU7 upgrade issue:
Lync Phone Edition CU6 Upgrade Issues – Jeff Schertz’s Blog

(His post discusses upgrading to CU6. The same process can be used for CU7.)

You must manually install CU5 to the phone, and verify its certificate, before attempting to install CU7. The steps for doing are listed in “Workaround” on the above-linked blog post.

(Using this process, you can even skip upgrading to CU6 and use CU7 instead.)

CU5 Not Available for Download at Microsoft; Download the Update File Below

Lync Phone Edition CU7 is available from Microsoft Support. However, Microsoft does not have CU5 posted on their Downloads site anymore! If you search for it, you will find a CU5 KB page. But clicking Download will give you a copy of CU7 instead.

Unfortunately, this is standard Microsoft practice. But it leaves all of us in the lurch on these phones!

Jeff Schertz again came to the rescue. He posted the CU5 download file (in .cab format) on his blog. In order to continue the goodwill, we’re offering the same file for download here:
UCUpdates_tanjay_CU5.cab

So there you have it. Download Lync Phone Edition CU5, install it on your CX700s following the Schertz procedure, and THEN you can upgrade the phones to CU7. It’s a workaround, yes. But for now, it does accomplish the goal.

Have you upgraded your Lync-enabled phones? How’d it go?

The other day, Larry and I sat down to install Lync Server 2013. Like all major server installs, complications arose during the process. We documented them, found solutions (either online, or through testing), and completed the setup. Lync Server 2013 now runs in our datacenter (yay!).

This post contains a full reference to the install process. Each post I wrote over the past few weeks, in sequence. Use these to guide your own Lync Server 2013 install.

I’ve included some comments below each link, so you’ll know what to expect.

How to Move to Lync Server 2013

Moving to Lync Server 2013: A Guide to the Installation Process
Before starting on a Lync Server 2013, prep your server hardware. Temporarily increasing RAM and disk space to the virtual servers (if you’re using Hyper-V) speeds up the install process.

Moving to Lync Server 2013: Starting the Install
Gather reference material before you start! These posts will help, as will a couple more links included here. First step, prepare Active Directory (and don’t rush).

Moving to Lync Server 2013: Creating a Lync Server Topology
We imported our existing Lync Server 2010 environment to speed up future migration. Next, setting feature options and server FQDNs in Topology Builder. Make sure you have proper file permissions set.

Moving to Lync Server 2013: Setup Lync Core Components
With a published topology, you can switch to the physical (or virtual) servers and install Lync’s core components. Then you’ll need to address certificate requests, which can get complicated.

Moving to Lync Server 2013: Build Out Mediation, Monitoring, Archiving and Edge
With core components in place, installing additional servers like Monitoring, Archiving, & Mediation are up. Pay special attention to Edge Server setup & configuration; you’ll need to address certificates for internal and external Edge.

Moving to Lync Server 2013: Error on the Front End
We encountered a major error with setting Edge certificates. But the problem didn’t reside in the Certificate Wizard…it was somewhere else. Thanks to a fix posted on Microsoft’s forums, we resolved the error and completed Edge setup.

Moving to Lync Server 2013: Adding Mobility and App Presentation
The last step for us? Installing Mobility Services and Web Apps Server. These are add-on capabilities for mobile Lync and presentations during conferences. Not required, but useful. And after a successful test, Lync Server 2013 is up and running!

Send Us Your Lync 2013 Stories!

Have you encountered issues with installing Lync Server 2013? Did you go about the install a different way? Send your stories in!

I’d love to share different Lync 2013 accounts. Or address quirks you’ve come across. Or both! Email me at chris.williams@planetmagpie.com, or leave a comment below.

Welcome to the last post in our series on the Lync Server 2013 install process. At this point, all of our primary Lync services are running – IM/Presence, Voice, Conferencing, Persistent Chat.

We used two testing methods to verify the services:
–Creating a dummy account to IM others (from two different workstations), AND
–Calling to & from this account, both to existing Lync users and to non-Lync numbers.

Everything’s behaving as it should.
So…let’s change it!

Or rather, add to it. There are two remaining services we want to add in: Mobility Services and Web Apps Server.

Installing Mobility Services

Mobility Services essentially allows you to use Lync on mobile devices (phones and tablets). It’s built into the Lync 2013 Front End Server, like Monitoring and Archiving were.

Which means its components are already installed! All you’d need to do is configure it.

You’ll find the deployment process for Mobility Services here: Deployment Process for Mobility – Microsoft TechNet

We also used 2 additional reference URLs:
Mobility for Lync 2013 – Lync Server 2013 TechNet Forums
Deploying the Lync 2010 Mobility Service – Jeff Schertz’s Blog

In fact, the Schertz article is so comprehensive that I will point you to it for configuration purposes.

There’s only one notation I can make. Our Mobility autodiscovery URL was lync.yourdomain.com. Thing is, we had this same URL as the Edge URL. Mobile autodiscovery didn’t work.

So we changed to lyncdiscover.yourdomain.com in DNS.

This caused a cert error, but that was related to our original firewall routing issue (which is NOT a Lync 2013 error). Bill, our networking expert, changed our routing paths to fix it.

Once you follow the Mobility Services configuration process, use the Powershell cmdlet Test-CsMcxP2PIM to test mobility service.

I grabbed my iPhone, and signed onto Lync. Test successful!

Installing Web Apps Server

Since we have conferencing enabled, the boss wanted Web Apps Server running as well. Web Apps Server is a new service in Lync Server 2013, intended to support using PowerPoint presentations while in Online Meetings. (It will also support presenting with the other main Office applications – Word, Excel, OneNote).

The Reference URL we used was:
Installing Office Web Apps Server for Lync Server 2013 – Microsoft UC and other stuff Blog

**Web Apps Server needs its own cert, and has to be trusted on Edge so discovery works. Bear this in mind.**

For Windows 2012, run the following PowerShell cmdlet:

Import-Module ServerManager
Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices,NET-Framework-Features, NET-Framework-Core, NET-HTTP-Activation, NET-Non-HTTP-Activ, NET-WCF-HTTP-Activation45

As you can see, this installs some required Windows components.

Next, download & run the Office Web App Server Program here:
Microsoft Office Web Apps Server – Microsoft Download Center
When you run it, you’ll be prompted for an install location. We kept the default, “C:\Program Files\Microsoft Office Web Apps”.

Click “Install Now” to run the install. When it’s done, click Close. Then we can proceed with configuration.

**NOTE** After installing program you must REBOOT in order to run the New-officewebappsfarm cmdlet. Otherwise the cmdlet is not recognized.

Before moving forward, create a local certificate for the WebAppServer or External Certificate. Our example uses the internal certificate:
New-OfficeWebAppsFarm -InternalURL “https://localhostnameofappserver.whateversuffixused” –CertificateName “Office Web Apps”

When using the above cmdlet, the certificate name must match the friendly name of the certificate. Otherwise you’ll run into a problem. Like this!

You can confirm the discovery URL for the OfficeWebApp server by going to the designated URL you defined (for instance, https://localhostnameofappserver.suffixused/hosting/discovery ).
An XML screen will appear.

Configuring Lync Topology for Web App Server

Open Topology builder and go to Site – Shared Components – Office Web Apps Servers. Right-click and select “New Office Web Apps Server…”

Type in the FQDN of the newly deployed Office Web App server. The Discovery URL field should auto-fill with the proper Office Web Apps Server URL.
(If you typed the web address rather than the FQDN, it will not auto-fill as expected. You’ll either have to cancel and redo the process, or type in the appropriate information as below.)

FQDN Format: webapp02.yourdomain.dom
Discovery URL Format: webapp02.yourdomain.dom/hosting/discovery

Click OK. Once that’s complete, you’ll need to associate the Office Web App Server to the Front-End server.

Right-click your Front End server and select “Edit Properties”. Under Properties –> General, scroll down to the File Store field. Choose “Associate pool with an Office Web Apps Server”. Then click the drop-down box, and select your newly built Office Web App Server.

Click OK. Then Publish your Topology again.

You can validate the Web App Server by reviewing the Lync Front-End server’s Event Viewer. You’ll have to look at the Lync Server logs. You’re looking for two event IDs: 41032 and 41034, to confirm a successful implementation.

When you see both of these, you’ll know Web Apps Server is up and running!

And that’s the last of our “Moving to Lync Server 2013″ post series! I’ll gather up all the links into a comprehensive guide later on.

Hope you’ve found these posts useful. As always, I like feedback from readers – what you’re working on with Lync, any issues you might run into, and so on.

See you next time, with more Lync Server content!

For this week, I have a short post documenting a serious error we encountered while installing Lync Server 2013.

A fix is available (thankfully). But it took us hours of back-and-forth research to locate it. I hope this post will save our readers all that time!

Stuck on an Internal Certificate Error…or Are We?

When we left off at Part 6, Larry and I were waiting for a new Active Directory server to finish installing. We wanted to use the new 2012 Certificate Services to issue internal certs for Lync Server.

Once AD had finished, we made a cert request. The cert issued, and we downloaded it to a file. The cert was placed in “Trusted Root Cert Authorities” for both the user and the Lync 2013 local machine.

However, we still had no luck. Lync would not recognize the cert.

Re-issuing the cert & adding it just to the local machine had more luck; it was recognized for “Web services internal” in Certificate Wizard. Recall that we already had an external cert for external Web services.

Everything looks okay now…but Lync’s not working. We were unable to connect to the server with a test account (not even for IM).

We tried reworking the cert, restarting the servers, going back in the Lync 2013 install process…nothing.

The error was not in the Certificate Wizard though. It was somewhere else.

Error: Lync Front End Service Appears Active (But Really Isn’t)

While we investigated, Larry checked the services running in the background. The Lync Front End service did appear in the services listing. Despite this, Lync would only connect for a moment–and then drop.

However, this service was a ghost!

According to this TechNet forum thread, the Lync Front End service had not activated properly.
Lync 2013 Enterprise Pool Front-End Service doesn’t start – Lync Server 2013 TechNet Forums

This error is NOT in current Microsoft documentation.

The solution was a fix from a Microsoft engineer (posted to the above thread by RSudmeijer):

Please note this will lower security so I don’t know if this has any security impact for Server 2012 and Lync. And if this will be the fix that Microsoft will offer. But the solution works for testing until further notice.

On the Front-End server create the following registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Create a registry key named ClientAuthTrustMode and set value to 2.

Restart the machine after making the changes. Once the server is restarted, check if the service is started.

This error only occurs during a migration from Lync Server 2010 to Lync Server 2013.

The fix corrected the Front End server issues, AND allowed for internal certificate retrieval.

Once Larry implemented this, we were able to test Lync 2013 via IM.

Larry also pointed the 2010 topology to the 2013 Edge server. External DNS must point to new Edge only. The new Edge Server (provided DNS is updated) will work for both 2013 and 2010 users.

And that’s how we fixed the most challenging error Lync Server 2013 gave us. All that’s left was installing Mobility services, installing the Web Apps server, and testing. Look for more on those next week!

First off, hello to everyone at the Lync Conference!

I really wanted to make it down, but it just didn’t happen. Makes me sad…lots of Lync announcements (and goodies) I’m missing out on!

If you want to follow the action (like me), check out these people on Twitter:
@LyncNewsTweets
@Matthewlandis
@whymicrosoft

Now, back to the Lync Server 2013 install process.

Last time, I mentioned that we had to upgrade Active Directory in order to acquire Certificate Services 2012. While we waited for it to install, Larry and I proceeded with building out Lync’s additional server roles: Mediation, Monitoring, Archiving, and Edge.

Mediation: In Place Already, SIP Trunk Needed

First up, Mediation. In Part 3 we’d selected the option to collocate the Mediation Server with the Front End pool. So it was already created. However, we needed to configure a SIP trunk for it.

We had already requested an IP for the SIP trunk; it came from a hosted SIP provider. To define it, we right-clicked “PSTN Gateway” in Topology Builder and selected “New IP/PSTN Gateway…”

Trunk Configuration steps are as follows:

• Define the PSTN Gateway FQDN (The field will accept an IP address as well)
• Enable IPv4 or IPv6. (We chose IPv4.)
• Sub-Option: “Use all configured IP addresses” or “Limit Service Usage to selected IP addresses”. We chose Limit Service Usage, and entered an internal IP.
• Define Root Trunk. We entered:
• A Trunk Name (the same gateway IP)
• A Listening port for gateway (the default is 5067; we changed it to 5068)
• A SIP transport protocol (default is TLS; we changed to TCP)
• Associated Mediation Server (we used the pre-set value)
• Associated Mediation Server port (default is 5067; it changed to 5068 when we changed the listening port).

Click Finish. Trunk configured! We tested it (later) by making phone calls to a test number.

Install Monitoring & Archiving Servers

Since Monitoring & Archiving Servers are add-ons to Front End in Lync 2013, all we needed to do was create a new SQL database for them, and configure the servers in Topology Builder.

Larry had created a new SQL database already, so we proceeded with installing the Monitoring and Archiving add-ons.

(If you need assistance setting up SQL databases for Monitoring and Archiving, refer to the first half of this post:
Step by Step Installing Lync Server 2013 Monitoring Role Collocated on Standard Edition Front End – Part 2: Matt Landis Windows PBX & UC Report )

Right-click your Standard Edition Front End Pool in Topology Builder. Click Edit Properties.

The Properties window should open displaying General properties. Scroll down until you see the “Archiving” option. Check the box.

Click the “New…” button next to “Archiving SQL Server Store”. A new window will open.

We entered the SQL database name (formatted like this: sql01.domainname.dom). We chose a Named Instance, and labeled it “Archiving”. We left the mirroring values on defaults. Click OK and you’re done.

Below this on the Properties window is the “Monitoring (CDR and QoE metrics)” option. Click “New…” next to this as well. You’ll see the same new window as Archiving. We entered the same SQL database name, but labeled this one “Monitoring” to differentiate. All other values left on defaults.

Click OK to close the box. And OK again to close Properties!

(Don’t forget to Publish the topology once these changes are made.)

Installing Edge

Certificate Services 2012 still had not finished setup. So we logged into the designated Edge Server instead.

We ran Lync Setup. After specifying an install location, the core components installed, just like the main Lync install.

Next, the Deployment Wizard pops up. Like I said in Part 2, install Administration Tools first (for Topology Builder).

After that, click “Install/Update Lync Server” like before. We selected “Import from File” when prompted, and navigated to the saved topology file in C:\Support.

1 Error: Prerequisite not satisfied.
Remember a few weeks ago, when I said to make sure Windows Identity Foundation” was installed? It wasn’t on this virtualized server. We opened Server Manager, added the “Windows Identity Foundation” service…and no more error.

Resuming Lync setup, I found that it auto-starts the prerequisite install. Plus it moves straight to “Install Edge Server”. You should see Installing Server.msi (Feature_Server_Edge) in the progress window.

Time to request a cert. We tried using the same cert as before (due to the multiple SANs listed within it). In the Certificate Assignment window, we deactivated “Edge Internal” for now (we’d need the local root from the new AD/Cert Services for that).

Right now, we’d just set up the External Edge certificate. We chose to “Import Certificate” from the saved text file; no problems. Then we clicked Assign.

Error! No certs appear in the list.

We tried this a few times with no change. Then Larry looked further into the cert structure. After many frustrating re-import attempts, he found the issue.

It turns out that the private key had not exported with the cert. Even though it was from the same server, we had to repair the key and re-export it before the Edge Server could see it.

*This was NOT a Lync-related error; it came from our own networking environment. I’m posting it in case you encounter the error as well.

Thing is, Lync Server 2013 DID give us an error right after this. A serious error that stopped us in our tracks.

I’ll devote the next “Moving to Lync Server 2013″ post to it.

Until then, join me in following the Lync Conference!

Last week, we left off with a published Lync topology. Once a topology is in place, you can begin installing Lync Server’s server roles on the prepared servers.

To do that, we return to the Lync Server Setup window. Moving on to “Install or Update Lync Server System”.

Today’s post will be a shorter one, made up mostly of the steps involved. This phase of the Lync Server 2013 install gave us the fewest problems. Afterward, we ran into some issues which deserve their own post. You’ll see those later.

For now, what’s the next step in installing Lync 2013? It’s below. Read on!

Install Lync Servers from Here

Click Install or Update Lync Server System. You’ll see a list of tasks, much like the Active Directory preparation tasks.

Step 1 is “Install Local Configuration Store”. With a published topology, this step essentially retrieves a local replica of the CMS and installs it.

Step 2 is “Setup Lync Server Components”. This step is the meat of the install. Here you’re installing the Lync Server component files. Prerequisites must be in place (it checks). “Setup Components” enables the new server roles, creates firewall rules, and sets up additional features needed to run Lync Server.

And we had zero issues with it! No setup issues here at all. Which is great. I hope none of you have any!

Requesting Certificates, and What Happens After

Next up is Step 3, “Request, Install or Assign Certificates”. This opens the Lync Certificate Wizard, and requests internal & external certs.

Certificates, I admit, are not my strong suit. Fortunately for me, Larry is well-versed in the subject.

He used DigiCert, an SSL Certificate management utility, to add SANs, or Subject Alternative Names, to verify all the Lync services we’ll need. We included simple URLs as well as SANs, to cover Edge, Mobility, Conferencing and Chat. Plus a few extra FQDNs for use with Web App Server and other services in the future.

We requested the certs through Thawte, using the CSR (Cert Signing Requirement) DigiCert provides.

Which kinds of certs? Well, there are two kinds. Internal certificate authorities are required for internal Web services, like authenticating users to the internal side of Edge. External certificate authorities are needed for all other FQDNs facing out to the Web.

Once we received the new external cert from Thawte, Larry copied it into a text file in the Support folder on Lync’s C:\. He then imported in into DigiCert, and entered a friendly name for easy reference (not required, but handy).

Note: In a cert’s Cert Path under Lync, all must be green-lit. No reds, which means it still needs a root cert.

With this new cert, we went back to the Lync Certificate Wizard. Click Assign to assign the cert. The imported cert is detected; it verifies as well. “Execute”.
2 warnings came back:

• Doesn’t match FQDN
• SANs don’t have assignments

We noted these for later repair.

But first, we had the internal cert to deal with. Larry created a local cert for Lync 2013 Web Services (Internal). He requested it on our IIS.

Here we had trouble – the IIS cert was not accepted. We had to troubleshoot Certificate Services, and found the following.

**IMPORTANT NOTE: If you’re running Certificate Services on Windows 2008, you may need to move up to 2012 Certificate Services.

This is NOT verified by Microsoft. But when we upgraded the Active Directory server (and moved up to Certificate Services 2012), we got the internal cert working.

Sadly, this was not the end of our certificate woes. But we proceeded with the Lync Server 2013 Install process anyway.

And that’s where we’ll pick up again next week!

Last time I took you through our initial steps on preparing servers and Active Directory for Lync Server 2013. We stopped at the Topology Builder.

Anyone who’s worked with Lync Server 2010 knows Topology Builder. In 2013 not much is different; we’ll use it to determine which server roles we want to run, and the IP information necessary to run them.

I’m adding all the Topology Builder steps into one post; makes sense this way. So pour some coffee, and let’s keep moving to Lync Server 2013!

Bouncing Off Existing Environment – Good for Migration

Because we have an existing Lync Server 2010 setup running in our domain, we chose “Download Topology from existing environment” on loading. This loaded two Lync Servers: one 2010, one 2013 (empty).

We’re adding all the bells and whistles we can to this version, since our datacenter is expanded and we have a hosted PSTN Gateway from Cohere ready to go.
(NOTE: Having IP information on hand for such hosted elements is critical!)

Expand the Lync Server 2013 folder. Right-click on “Standard Edition Front End Server” and click “New Front End Pool…”.
(If you plan to use Enterprise Edition, right-click the “Enterprise Edition Front End Server” and click “New Front End Pool…” instead.)

A new window will open, asking for details to define the new Front End pool. First, enter your Fully Qualified Domain Name (FQDN). For example, mslync03.domainname.com.

Next up is the Feature Select window. Select which Lync Server features you want to run.

We selected all options (as seen above), EXCEPT Archiving and Monitoring. Why no Archiving or Monitoring? We didn’t have SQL databases prepared for them yet. Once those are ready, we’ll re-enter Topology Builder and add them.

(This is also a recommended step in Matt Landis’ post series on installing Lync Server 2013. You’ll find it here:
Step by Step Installing Lync Server 2013 Standard Edition Front End on Windows 2012 – Part 1: Matt Landis Windows PBX & UC Report)

Down through the Feature Options

At the next screenshot you’ll define your Mediation Server. Necessary component for voice communications. We followed Ondrej’s example and chose “Collocate Mediation Server”.

Next, you’ll see a screen asking to associate Server Roles with this Front End pool. We selected Edge.

Define SQL Server Store: We had a SQL 2012 database prepared for this; selected “New” and entered it.

Define File Store: At this point we left the Topology Builder running, & switched directly to the Windows Server we were installing on. Why? To create a folder called “LyncShare”, which will be our file store.

This folder must be accessible to ALL users on this server, so Lync has no trouble storing/using files. Be sure to right-click the folder and share it with everyone.

Then we can go back to Topology Builder, and define a new file store using our server’s FQDN and the new shared folder.

Next up, Specify Web Services URL. Enter an external FQDN (for example, lyncexternal.domainname.com). It can be anything really, but make sure it’s NOT the same FQDN you use for your Edge Server later. We used a brand new FQDN to avoid any association issues with our 2010 system, as well.

We skipped the option of setting up an Office Web Apps Server – again, something to add later.

Next you’ll see options for specifying an Archiving SQL Store and a Monitoring SQL Store. Since ours weren’t enabled yet, we turned these off for now.

After that, it’s time to define an Edge Server pool.
Extra information is required to set up Edge Servers: their own IP, FQDN, multiple Edge servers vs. a single server, etc. Lucky for all of us, Topology Builder gives you reminders for all of it.

So if you don’t have something, just leave it up and go find what you need.

We entered our Edge FQDN, and selected “Single computer pool”. Right now, we don’t need load balancing in place.

Edge Features Selected: Use single FQDN and IP address, Enable federation, Enable XMPP Federation. We selected all of them.

IP Options: You can define IPs by IPv4 OR IPv6! Very useful in the coming year. We stuck with IPv4 for now.

External FQDNs: Lync will ask for 3 FQDNs – one for Access Edge, one for Web Conferencing Edge and one for A/V Edge. We used the same FQDN for all three.

(Again, DON’T use the same FQDN as the one you input for external Web services! We had a lot of grief to deal with when we did that.)

Edge Setup will then ask for internal and external IP addresses. External IP is a private IP used for Edge services alone. We added in a new external IP for NAT, which figures into the Public IP.

Define Public IP: This is for the A/V Edge service. We used the same IP as the External IP.

Next Hop: The last step in Edge Setup. You must select a Front End or Director pool to serve as the Edge’s next hop. If you had a Director, this would give you the option of selecting it. Since we’re on Standard Edition, Next Hop is automatically filled in with the Front End pool’s FQDN. Just click Next, and Edge Setup is done!

One more step. Topology Builder should have finished its wizard. But before you publish, make sure to define an administrative URL for future work. We had one prepared – something similar to http://admin.lyncpm.com.

Right-click the new topology, and select Edit Properties. Scroll until you see the “Administrative access URL” field.
Enter your administrative URL. It must correspond with the Front End pool FQDN you set earlier.
Below this field, in the “Front End Server to install Central Management Store to” menu, select your Front End server. Click OK to save changes.

All set (for now)! Right-click the new Lync 2013 Server and click Publish Topology. Click “Next” twice to complete the publication.

Uh oh…error! Error! What’s happened?

It appears we have an Access Permissions error.
(( ACL Error: Failed Adding “Access Write” permission for “RTCHS Universal Services” on “LyncShare”. ))

The file store? Yep. Turns out this is a relatively common error that occurs with sharing of the file store folder. Engineers at FortressITX located a fix, and posted it on Quora:
How Can I fix the Microsoft Lync 2013 Installation Topology Error? – Quora

It essentially requires you to go overboard on sharing the file store with admin groups. We followed the steps and wound up with this:

And what do you know, the topology published after that!

You now have an active Lync Server 2013 topology. The next step will be to install the Lync Server software on its appropriate servers, and define roles such as Edge and Archiving.

Again, please note that a Lync Server topology is not set in stone. Today’s build establishes the functionality baseline for our Lync Server system. We’ll add to it as we go along. Just as any administrator can add to/change their Lync Server.

Check back next time for Part 4!

Sorry this post is late! We’re still finalizing our new Lync Server 2013 installation. Some configuration issues (not part of Lync itself) are slowing us down.

But I have plenty of notes on how we began, so I’m ready to blog about the process!

Larry, one of our senior engineers from the IT Consulting division, did most of the setup work. I shadowed him to document the process and pitch my own experience in as needed.

First, Gather Sources

To inform the install process we collected several references, including:
Lync 2013 RTM migration from Lync 2010 Step by Step – Part 1: Ondrej Stefka’s Blog
And
Installing Office Web Apps Server for Lync Server 2013: Microsoft UC and other stuff Blog
To start.

We installed a fresh (virtual) Windows 2012 server in our datacenter. And a second (also virtual) server, for the 2013 Edge Server. Both were joined to our domain.

Next, according to Ondrej’s blog, we used PowerShell to install prerequisites. You MUST have elevated permissions to run these commends!

The PS command we used was:

Add-WindowsFeature Windows-Identity-Foundation, RSAT-ADDS, Web-Server, Web-Static-Content, Web-Default-Doc, Web-Http-Errors, Web-Asp-Net, Web-Net-Ext, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Http-Logging, Web-Log-Libraries, Web-Request-Monitor, Web-Http-Tracing, Web-Basic-Auth, Web-Windows-Auth, Web-Client-Auth, Web-Filtering, Web-Stat-Compression, Web-Dyn-Compression, NET-WCF-HTTP-Activation45, Web-Asp-Net45, Web-Mgmt-Tools, Web-Scripting-Tools, Web-Mgmt-Compat, Desktop-Experience, BITS

(You can copy this command directly into PowerShell, either from here or Ondrej’s blog.)

Reboot the server, to make sure all prerequisites are running. You may receive a Visual C++ 2012 Runtime install prompt. If so, click Yes and let it install too.

*Note: Make sure the Windows Identity Foundation is properly installed. It will trip you up later on if not. To make sure (and to install it yourself if necessary) follow these steps:

1. Open the Windows Server 2012 Server Manager.
2. Run the Add Roles and Features Wizard.
3. Select Features.
4. Select “Windows Identity Foundation 3.5″ from the list.
5. Click Next, then click Install.

Next we loaded the Lync Server 2013 installation software (to its default location). The Deployment Wizard came up, displaying a familiar sight to anyone who’s installed Lync Server 2010:

The first option to take is the same as 2010, too: Prepare Active Directory.

Preparing Active Directory? Make Sure You Have FULL Admin Privileges!

Our first snag came at this stage. Fortunately, this one was easy to fix.

Click “Prepare Active Directory.” You’ll see the following image.

Prepare AD Schema by clicking Run. It should run without incident. We however did have an incident – an error flared up. The problem? Our login used was not a member of the “Schema Admins” group. Once we fixed this (and logged out/logged back in), schema preparation worked.

When the schema are prepared, go to Step 3: Prepare Current Forest and click Run.

(We did not verify the Replication of Schema Partition manually, as Step 2 says. This is because we were only dealing with 2 Domain Controllers. If you have more Domain Controllers than that, follow Step 2.)

The forest preparation went through, no problem. However, we were a bit impatient and proceeded to the next step right away. It stifled us a bit, as you’ll see.

Because we had an error earlier, we decided manually verifying Step 4 (Verify Replication of Global Catalog) was worth the time!

But no error was present (so far). We proceeded to Step 5, “Prepare Current Domain.”

Here’s where we ran into a snag. “Error: Forest is Not Prepared.”

We went too fast. The forest replication hadn’t finished yet. Not wanting to wait, Larry forced replication on the Domain Controller directly. (If you’d rather just wait, Lync Setup estimates a max time of 15 minutes for replication to occur. Grab a coffee.)

Afterward, we still had a replication issue, saying that 2 groups were not found. “CSResponseGroupManager” and “CsPersistentChatAdministrator.”

Larry decided to reboot the Domain Controller. We restarted Lync 2013 Setup after that.

*Important Point: The Lync Server 2013 Deployment Wizard automatically saves its current state whenever you finish a task. This is done so that if you need to reboot, or cancel the installation & return later, you don’t repeat tasks already completed.

After the reboot we returned to the Deployment Wizard. But before we resumed setup, Larry wanted to confirm that his account was in the CsAdministrator group. He suspected that the replication issue involving the groups came from there.

His account is listed in the CsAdministrator group, so we proceeded. Sure enough, “Prepare Current Domain” ran smoothly.

Once Active Directory had been prepared, we were returned to the Deployment Wizard. Now, here’s where I have to point out a flaw in Microsoft’s organization of the Wizard. The next step to take is NOT “Install or Update Lync Server System.” You might think it is because it’s right below “Prepare Active Directory.”

But the next step you should take is over on the right. It’s “Install Administrative Tools.”

Why? One reason: Topology Builder.

You Need Topology Builder to Build Your Lync Server System

Topology Builder is installed when you click “Install Administrative Tools.”

For those of you who are new to Lync Server, Topology Builder is a tool which allows you to map out and set initial configuration for your entire Lync Server setup. In Topology Builder you determine how many servers you want to run. Which Lync services they’ll run (Monitoring, Edge, Mediation, etc.). Where they’re located in your network. Your IP addressing.

All of this is determined within Topology Builder. It then generates a Lync Server Topology, which all Lync servers use to map their pre-set roles. Think of a Topology like the set of instructions they all follow.

Without those instructions, you could click on “Install or Update Lync Server System”…and the servers would be confused. Where do I belong in the network? What role am I playing?

Avoid all that by installing Administrative Tools first. Then, start Topology Builder.

Next post, I’ll run through all the steps of creating a new Lync Server 2013 topology. Look for that early next week. We may move to 2 posts a week to cover all of this information.

Don’t worry though. When we’re completely through the “Moving to Lync Server 2013” post series, I’ll collect all the post URLs into one, so you’ll have an easy reference!