Updated: September 16, 2013 : As mentioned in the comments, the September 2013 update for Lync 2013 reverts the System Tray functionality back to the pre-July 2013 update.  HOWEVER, as also mentioned...a bug causing issues with Outlook was found and the release has been pulled.  They are working on fixing the update and will re-release it shortly.

UPDATED July 10, 2013 : Based on negative feedback from customers, the Lync Product Group is planning on reverting this change.  No ETA / Target CU has been given.

As part of Cumulative Update 2 for the Lync 2013 client, the Lync Product Group has made a change that users will need to be aware of.

Since Live Communications Server (LCS) and the Communicator client, the Lync System Tray Icon has always changed colors to indicate your status as it's seen by others (e.g. Green means available, Red means busy, Yellow means away, etc).

Starting with the July 2013 Security Update for Lync 2013 and Cumulative Update 2 for the Lync 2013 Client (not yet released as of this post's writing on July 9, 2013)...the Lync 2013 System Tray icon has been changed to simply be the blue Lync 2013 logo:

It no longer will change colors to show your status.  To see your status, you will need to hover your mouse over the icon:

This change was made to align Lync 2013 with the overall Office 2013 design standard for the System Tray icons.  I wanted to make people aware of this change as it is something users will see after the July 2013 Security Update is deployed and is a major change in the way the Lync System Try icon works.

So, ran into a little issue in my lab that I thought I'd share...since the solution wasn't readily apparent (at least at first).

So, I was trying to install a Lync 2013 Standard Edition server as the first server in an org.  The server name was Lync15SE (lync15se.contoso.com).  While going through the Lync Topology Builder, I got to the question about what the Pool name would be.  Not giving it a ton of thought, I entered "lyncpool.contoso.com".  I then finished configuring everything in Topology Builder that I needed and went to Publish Topology.  The publish failed with it complaining:

Error: Cannot open Service Control Manager on computer "lyncpool.contoso.com".  This operation might require other privileges.

At the time, I was doing the install as the Enterprise Administrator...it has all the rights in the world, what permissions could be missing?  Or is something blocking an Enterprise Admin from doing this in Lync 2013 (I didn't remember a problem using that account with Lync 2010).

I tried uninstalling SQL Express, making sure lyncpool.contoso.com was in DNS, re-running the setup of the Configuration Manager, tried setting up and using a service account instead of the Enterprise Administrator account...all to no avail.  I searched Technet as well as our internal Microsoft Knowledge Bases...everything I found said it was a permissions issue.

Finally, it dawned on me...Standard Edition pool names MUST be the server name.  Only with Enterprise Edition can you create a separate pool name.

I went back into Topology Builder and changed the pool name to lync15se.contoso.com (the SE server's hostname) instead...and VOILA, I was able to publish.

I think (I haven't gone back and verified) that Lync 2010 Topology Builder checked (or prevented you) from using a different name for a Standard Edition server.  Lync 2013 RTM definitely does not.

Update December 4, 2013: In the November 2013 update for the Lync 2013 Client, they changed the icon for the Upcoming Meetings list to a mini calendar:

--------------------------------------------------------------------------------------------------------------------------------------------------

As I mentioned in my other post about the change to the Lync 2013 System Tray Icon, that change was part of a larger number of changes planned for Lync 2013 Cumulative Update 2 (CU2) but went into effect as part of the July 2013 Security Update for Lync 2013.

However, unlike that change which caused a lot of negative responses from customers (and is now planned to be changed), there are a couple of other features related to CU2 that also are exposed in the client once the July 2013 Security Update is installed that are neat new features.  I wanted to make you aware of them...

Meetings Tab

This new feature adds a new Icon in the main Lync window that when clicked upon, displays a new tab that shows you upcoming meetings (meetings in the next 24 hours):

With this new tab/feature, users do not have to rely upon Outlook (or other clients) to see their upcoming meetings or to join them.  Now, a user can simply use the Lync client to see and join the meetings.  Lync pulls this information out of Exchange via Exchange Web Services (EWS).  It checks for new meetings every 10 minutes.

New Join Meeting Options

This feature adds a new options section called "Lync Meetings" to the Lync Options area.  In this new section you can configure:

• When you join meetings, should Lync show the Participant List (which was hidden by default previously).
• When you join meetings, should Lync show the IM Chat Window (which was hidden by default previously).
• One additional option is the ability to specify which client/app to use to join meetings.  With the ability to have multiple clients and apps installed which can support Lync Meetings, the need arose to allow users to set which client to use to join a Lync meeting.

Background

Over the past 6 months, our BPOS support team has been trying to get to the bottom of issues some customers were experiencing with Outlook Anywhere where Outlook (2007 & 2010) reports that it is connected but when a user tries to send email the message sits in the Outbox and does not get sent unless you restart Outlook.  The issue was finally determined to be related to “keep alives” between the client and server and timeouts on network devices between the end-user and the Exchange CAS. 

While you may not be using BPOS, this issue may be seen in ANY Exchange environment (including Office365) where Outlook Anywhere is used and so I want to make you aware of it and our recommendation to resolve it. 

The Issue

By default, Outlook Anywhere opens two default connections to the Exchange CAS called RPC_InData and RPC_OutData.  the Outlook Anywhere client to server used a default timeout of 12 minutes (720 seconds) of inactivity and the server to the client timeout is 15 minutes (900 seconds).

These default Keep-Alive intervals are NOT aggressive enough for some of today’s home networking devices and/or aggressive network devices on the Internet. Some of those devices are dropping TCP connections after as little as 5 minutes (300 seconds) of inactivity.  When one or both of the two default connections are dropped, the connection to the Exchange server is essentially broken and not useable.

Solution/Recommendation

To address this issue, we are recommending setting a registry key on the Exchange CAS to change the default Keep-Alive from 15 minutes (900 seconds) to 2 minutes (120 seconds):

HKLM\Software\Policies\Microsoft\Windows NT\RPC

MinimumConnectionTimeout DWORD  0x00000078 (120)

When present, this setting specifies the minimum connection timeout used by the client and RPC Proxy, in seconds.  The actual timeout used is the lower of this value and the IIS idle connection timeout.  If zero, or the key is not present, the IIS idle connection timeout is used.  Used only in RPC over HTTP v2. When changes are made to this value on the RPC Proxy, IIS must be restarted for the change to take effect.  See http://msdn.microsoft.com/en-us/library/windows/desktop/aa373592(v=vs.85).aspx for reference.

The Outlook client honors this new default during the connection to the server so both the Outlook client and the Server now send a Keep-Alive packet after 2 minutes of inactivity, effectively maintaining both TCP connections needed.

This change has almost negligible impact on the Exchange server, as it simply sets the Keep-Alive interval.  By setting the timeout to 2 minutes, it is below the 5 minute timeout that a device between the user and Exchange server may be using and therefore allows the connections to "stay alive".

Recently, an issue that has been around for some time started generating a lot of renewed interest.  The issue I'm referring to is regarding Exchange users still having access for several hours after their AD Account has been disabled.  This post is Part I of II, discussing why this happens and best practices to properly deal with/cut off access to users as quickly as possible relating to ActiveSync.  In Part II, I  will discuss this issue as it relates to Outlook and OWA and the best practices on how to deal with them

The main issue of concern is that if a user is terminated and just their AD account is disabled (which is a fairly standard process for many companies), that once their AD account is disabled it’s believed that the user is now stopped from being able to access anything using Windows Authentication, such as Exchange).  However, that may not necessarily be true…especially with ActiveSync.  If we’re talking about a terminated employee who was “walked out the door” and you want to IMMEDIATELY stop them from being able to send/receive emails via an ActiveSync device and all you've done is disable their AD account, they may still be able to sync for some time and send emails that you don't want sent.  This can then open a whole slew of headaches.

Why Does This Happen?

The ability for ActiveSync to continue to work even though the user's AD Account has been disabled is because of several reasons.  One of the main reasons is due to the way ActiveSync keeps a connection open to the server to watch for new messages.  That connection has already authenticated and has been validated…so while the AD count may be disabled, all Exchange knows is that the user HAD rights to the mailbox and is continuing to use that connection.  Eventually, the “life” of that authentication expires and the user has to re-authenticate (which is all done transparent to the user) and if the account was disabled, the re-authentication will fail and the user will no longer be able to sync.  ActiveSync devices with their long heartbeat intervals and token cache can still allow access up to 24 hours after an AD account has been disabled.  This is also related to caching done by IIS and Exchange, which I will talk about more in Part II.  But, in summary, just disabling a user's AD account will likely not stop them from accessing Exchange for at least a couple of hours if not more. 

Best Practices to Follow Regarding Disabling User Access

1. Before disabling the AD Account, you should do the following:

a. Trigger a remote wipe of the device - OPTIONAL

This may or may not be something you want to do depending on your company’s policies, if it’s a personal device, etc.  However, once the sync is stopped through other means the device cannot come in and get the Wipe Request, so this is one of the first things that should be done if your company deems it necessary.

b. In addition, implement a block of all their devices (if you didn't issue a remote wipe and/or their device doesn't support remote wipe, etc):

If using Exchange 2010/Office365:

Get information about the user and devices

Get-CASMailbox <user> | Select ActiveSyncAllowedDeviceIDs, ActiveSyncBlockedDeviceIDs

Get-ActiveSyncDeviceStatistics –Mailbox <user> | fl DeviceID

Block all Devices for a user

Set-CASMailbox -Identity <user> -ActiveSyncBlockedDeviceIDs "<DeviceID_1>,<DeviceID_2>"

If using Exchange 2007:

Get information about the user and devices

Get-CASMailbox <user> | Select ActiveSyncAllowedDeviceIDs

Get-ActiveSyncDeviceStatistics –Mailbox <user> | fl DeviceID

Block all Devices for a user

Set-CASMailbox -Identity <user> -ActiveSyncAllowedDeviceIDs "BLOCKED"

(Note: The use of the string “BLOCKED” is to enter a string that does NOT match any device they may be using as setting this value will ONLY allow a device with that Device ID string to sync [which no real device would have the Device ID of “BLOCKED”] and all others to NOT be allowed to sync)

c. Disable ActiveSync:

Set-CASMailbox -Identity <user> -ActiveSyncEnabled $false

d. Disable the mailbox (at least temporarily) - OPTIONAL

Note: It’s understood that some companies leave the mailboxes enabled to receive email so that OOF/automatic responses can be generated or so that no emails to the address are not blocked.  If this is the case, it’s recommended that you disable the mailbox for approximately 30m-1h and then enable again.  This will allow time for the change to go into effect and stop allowing ActiveSync to access.  This solution is in lieu of ActiveSync disabling as outlined above.

2. Disable the AD account

Do note, the above changes are NOT instantaneous!  It can take around 5-10 minutes for the ActiveSync device blocking to go into effect, and that’s from the time that the change is replicated to all the DC/GCs used.  Obviously, if you make the changes against a DC/GC in another site and it has to replicate to the Internet-facing Exchange site(s) more time is needed.  The other settings can take up to 20 minutes to go into effect due to caching.

You may ask why we recommend using –ActiveSyncBlockedDeviceIDs AND –ActiveSyncEnabled?  It’s because the check for ActiveSyncBlockedDeviceIDs is checked almost continuously, since that part of Exchange is designed around the premise that devices are added or removed regularly.  However, ActiveSyncEnabled’s setting is cached for up to 20 minutes and then may only be rechecked if IIS Token Caching has expired.