Wanted to make you aware of a change made in Outlook 2013 with the October 2014 updates.
After installing the October 2014 update for Outlook 2013, when you click on the Deleted Items folder, you’ll find a new button on the HOME tab for that folder: Recover Deleted Items from Server
This change was made at the request of our Office 365 support teams, to make it easier for users to find this ability. They were receiving, on average, 400 calls a month from users who didn’t know how to get back items deleted or that didn’t know they had to click on the FOLDER tab to find this option.
No documentation has been posted yet regarding this change and probably wont be as it's such a minor change. However, I thought support folks might like to be made aware of it in case you get questioned about it or notice it. The Recover Items option is STILL on the FOLDER tab as well.
There are plans to also make this change to Outlook 2010 in the November 2014 update for Outlook 2010.
As I mentioned in the Current Cumulative Updates for Office - Q3 2012 post, each quarter I will post information on the latest updates for the Office for Windows and Office for Macintosh products.
The information below is being provided regarding the most currently available updates available for the supported Windows and Macintosh versions of Office as of October 1, 2014.
As a reminder on why I'm providing this information and how it should be used, please see my Keeping Up with Office Updates post which discusses the cumulative updates for Office (and Outlook in particular) that companies need to be aware of and push out to their users.
Note: Each of the KB articles includes the list/links for all the Office products (Word, Excel, Outlook, etc). Most of you focus on Outlook and that’s the only ones required and is also provided separately but I wanted to provide the larger “Office” list in case you want it.
As a reminder, Microsoft Update does *NOT* make the cumulative updates available to users. These have to be downloaded and either installed independently or deployed using tools such as WSUS, SCCM, etc.
Note: Each of the KB articles includes the link for downloading the package which updates ALL Office Products…there are not separate updates for each of the various components of Office as there is with the Windows releases.
First, my apologies in advance for my being a bit long worded in this post, but I thought this was the best way to communicate and explain this…
An issue that has troubled customers for many years is that many of our products use or rely on other products of ours. While that in itself is not an issue (and we consider it a benefit), the issue it causes is that updates from one product group do NOT contain updates for the other products. In some cases, when an update for another product is required, the PG team will add in a pre-verification check letting you know that you need to install another product’s update first, but that's about it.
However, fixes/updates to other products that are nice to have or recommended do NOT fall into this category. And since most customers do not run Windows Update on the servers, but instead simply deploy known patches/updates/rollups/CUs manually, they may not be aware that other updates may be needed.
For Lync, the main other product we rely upon (besides Windows) is SQL (both full SQL and SQL Express). Many customers ask if Lync is supported/works with the latest SQL service pack (this question mainly comes up because the SQL team wants to deploy it to the SQL servers used by Lync, so the Lync team asks us if it's supported). However, what gets overlooked is the copy of SQL Express that sits on all the Lync servers. And, again, unless you’re occasionally running Windows Update to see what updates are available, you may not think of it as well (I'll even Microsoft support folks sometimes forget about it too). The other situation where this also arises, is with Standard Edition servers…which completely use SQL express and may not be maintained by your SQL teams.
Now, why did I just ramble on about this? SQL 2012 SP2 was released a few months ago and contained several performance fixes. Customers deploying it to the instance of SQL Express running on the Lync servers are seeing noticeable performance improvements.
So, in summary, on your next patch cycle for your Lync environment (say to deploy the latest updates…*hint* *hint*), be sure to include applying SQL 2012 SP2. As well as on your Lync 2010 environments, be sure to apply SQL 2008 SP3.
For customers still using OCS, this recommendation is also valid but only if you have OCS Standard Edition servers (which, like Lync Standard Edition servers, use SQL Express).
The information below is being provided regarding the most currently available updates available for the supported Windows and Macintosh versions of Office as of April 10, 2014.
The information below is being provided regarding the most currently available updates available for the supported Windows and Macintosh versions of Office as of January 2, 2014.
So, I consider myself a pretty good PowerShell user/scripter. But, I was stumped by a small issue with trying to use the "Remove-ActiveSyncDevice" cmdlet in Exchange 2010 to not prompt for each device removal.
Our (Microsoft) TechNet article on using Remove-ActiveSync Device (http://technet.microsoft.com/en-us/library/bb125032(v=exchg.141).aspx) did not provide a lot of help. It tells you there's the "-Confirm" parameter and that it will cause you to be prompted, but does not say how to get it to NOT prompt.
If you try "-Confirm $false", you'll get the following error back:
A positional parameter cannot be found that accepts argument 'False'. + CategoryInfo : InvalidArgument: (:) [Remove-ActiveSyncDevice], ParameterBindingException + FullyQualifiedErrorId : PositionalParameterNotFound,Remove-ActiveSyncDevice
This method: DiRECTIVE + SPACE + VALUE is a normal way of running commands and providing values. But, for the "-Confirm" directive and the Remove-ActiveSyncDevice cmdlet (I suspect this is true with most Exchange cmdlets) you CANNOT use that method. You MUST use DIRECTIVE + COLON + VALUE: -Confirm:$false
With that, it will NOT prompt.
I'm sure there's lots of folks out there that already knew this...especially if you normally use the method with colons, you probably didn't even realize this was an issue. For the rest of us, this is one of those things where what should/would normally work with other directives (using a space) does not work with -Confirm.
I recently ran into this and wanted to share, as I'm sure others may run into this as well.
As many of you may know, Windows RT 8.1 includes a version of Outlook 2013...so that you're not limited to just using the Windows Mail app...which is great! However, what many may run into is that the default location for storing your OST is C:\Users\<login>\AppData\Local\Microsoft\Outlook. Which, if you have the 32GB Surface (or equivalent) you probably don't want a big OST file eating up your space. In my case, I installed a 32GB SDHC in my Surface RT and wanted the OST to be there.
The issue is that you can only set where the OST file is created during Profile creation...not once you've setup the profile. If you try once the profile is setup, the option to Browse and select where the OST file goes is grayed out.
This KB article http://support.microsoft.com/kb/2752583 explains how to set where to put the OST during Profile creation and *is* also applicable to Outlook 2013 on Windows RT.
The information below is being provided regarding the most currently available updates available for the supported Windows and Macintosh versions of Office as of October 1, 2013.
Recently a customer asked me for a way to determine which Lync 2013 client their users had installed (basic vs. full) using the registry. We don't have this well documented (ok, to be honest I could not find any documentation on it), so I did some testing in my lab and put together the following information for them...which I thought I'd share as I'm sure others may have this same question.
If you just want to verify if ANY version (Basic, Full, or as part of Office 2013 Pro) of Lync 2013 client is installed, you can use the following registry key:
For 64-bit Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\15.0\Registration\{0EA305CE-B708-4D79-8087-D636AB0F1A4D}
ProductName = "Microsoft Lync 2013"
For 32-bit Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\15.0\Registration\{0EA305CE-B708-4D79-8087-D636AB0F1A4D}
The following registry value will exist if the Lync 2013 Basic client is installed:
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\Office15.LYNCENTRY
DisplayName = “Microsoft Lync Basic 2013”
Note the name of the key, it is DIFFERENT between Lync 2013 Basic and Full.
The following registry value will exist if the Lync 2013 Full client is installed:
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\Office15.LYNC
DisplayName= “Microsoft Lync 2013”
Lync 2013 as part of Office 2013 Pro does NOT have its own registry key, since its installation is controlled by the Office 2013 Pro setup. So, a way to detect if Lync 2013 is installed as part of Office 2013 Pro would be to use the first key I provide above (to determine Lync 2013 is on the system) and the ABSENCE of the other keys above would denote that Lync 2013 was installed as part of Office 2013 Pro.
Hope this helps. Note that this is NOT an all inclusive list of registry keys...as there are other registry keys that could also be used that exist depending on if Lync 2013 is installed and/or which version of Lync 2013 is installed.
Several customers are reporting an issue after installing the July 2013 Security Update for Lync 2013 related to icons not be rendered correctly or missing entirely. This issue has been found to be related to other updates missing on the workstation, as those other updates are NOT part of the July 2013 Security Update…but are required for other changes in the Lync 2013 Client to work properly.
In addition to the July 2013 security update for Lync 2013 (KB2817465), you MUST also install the latest Office 2013 updates for MSO.DLL and MSORES.DLL (KB2817491). These are available from Windows Update or downloaded via the KBs.
We are working to have the KB for the July 2013 Security Update for Lync 2013 (KB2817465) updated to include this information.
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...
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.
This feature adds a new options section called "Lync Meetings" to the Lync Options area. In this new section you can configure:
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.
One of the great things the Exchange Product Group did, starting with Exchange 2007, was to start generating informative log files as part of the installation/upgrade process. Gone are the days when you had no log files and you got 75% of the way through and the setup program bombed with some generic error and that's all you got (maybe an event in the Event Viewer as well, but still not a whole lot to go on). These logs are written to C:\ExchangeSetupLogs by default.
However, I recently worked on an issue with one of my customers on an Exchange 2010 SP3 upgrade. They had all the setup logs, but hadn’t followed any of the best practices I’m about to talk about. This resulted in having to deal with VERY large log files in the C:\ExchangeSetupLogs directory that had everything in them since the server was first built. So, I wanted to post some information out on best practices related to these files…
One of our best practices *is* to keep all your setup logs…which most customers do. However, there are a few related best practices I wanted to share that go along with this:
The biggest advantage to following these best practices is simply that if you run into issues with an upgrade (or after), you’re not dealing with the huge log files (especially if opening them with Notepad) or a directory with hundreds and hundreds of files in it. This can make troubleshooting a little easier. Hopefully, you’ll never need these files, but that never seems to be the way it works out.
The information below is being provided regarding the most currently available updates available for the supported Windows and Macintosh versions of Office as of July 1, 2013.
As I mentioned in the Current Cumulative Updates for Office -Q3 2012 post, each quarter I will post information on the latest updates for the Office for Windows and Office for Macintosh products.
The information below is being provided regarding the most currently available updates available for the supported Windows and Macintosh versions of Office as of April 8, 2013.
The information below is being provided regarding the most currently available updates available for the supported Windows and Macintosh versions of Office as of January 3, 2013.
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.
The information below is being provided regarding the most currently available updates available for the supported Windows and Macintosh versions of Office as of October 1, 2012.
Almost a year ago, I posted Keeping Up with Office Updates which discusses the cumulative updates for Office (and Outlook in particular) that companies need to be aware of and push out to their users. For my direct customers, every quarter I send an email letting them know what the latest updates currently are. However, I realiezd that others might benefit from having this information as well (and not having to go and piece it together themselves). So, going forward every quarter I will post that information here as well.
The information below is being provided regarding the most currently available updates available for the supported Windows and Macintosh versions of Office as of July 6, 2012.
In Part I, I provided information regarding users’ mobile devices still being able to synchronize with Exchange (via ActiveSync) even after their AD Accounts have been disabled. I included related best practices on how to stop devices from syncing as quickly as possible.
Here, in Part II, I’m going to discuss a similar issue with Outlook and OWA and the best practices on how to deal with them. Be aware that in many places I will only mention “OWA”, this information is also applicable to all web-service related Exchange connectivity such as EWS (used by Outlook for Mac 2011, etc) and Outlook Anywhere.
To recap the issue I’m referring to:
Many companies simply disable the AD Account when an employee is terminated and assume that very quickly (e.g. within a couple of minutes) the user will no longer be able to access any Windows Authentication-based resources, including Exchange through any of its access methods, because the AD Account has been disabled. Unfortunately, that is NOT correct. For many hours after the AD Account has been disabled, users may be able to continue accessing Exchange and be able to send, receive, etc. This happens for a number of reasons (which I’ll discuss below) and can become a huge issue, especially when dealing with terminated employees who have been “walked out the door”.
First and foremost, in order to scale and be efficient, a lot of caching goes on within IIS and Exchange. IIS plays a major role here as the Exchange-based web services run under IIS. Besides the caching in IIS, Exchange also does its own caching…more than just data caching in memory, but active connections to the store (Exchange 2007) or RPCClientAccess (Exchange 2010) are cached for up to 2 hours which effects the authentication of Outlook MAPI (RPC) connections.
The main component/feature of IIS involved is User Token Caching in IIS. The default is 15 minutes, and so if a connection is made within 15 minutes of the last connection the cached token information is reused instead of checking with AD. You can adjust this value (see KB152526), but be aware that reducing this time will put additional load on the DCs and depending on open connections may still not go into effect quickly. Also, be aware that while Internet Explorer (IE) will very strictly follow this, other browsers have been found to NOT do so and so this can mean other browsers may continue to provide access when IE no longer does.
Here are the best practices related to Outlook and OWA:
For Exchange 2007:
Set-CASMailbox -Identity <user> -OwaEnabled $false
For Exchange 2010:
Set-CASMailbox -Identity <user> -EwsEnabled $false
Set-CASMailbox -Identity <user> -EcpEnabled $false
Set-CASMailbox -Identity <user> -MapiEnabled $false
Set-CASMailbox -Identity <user> -MapiBlockOutlookRpcHttp $true
Set-CASMailbox -Identity <user> -EwsAllowMacOutlook $false
Set-CASMailbox -Identity <user> -EwsAllowOutlook $false
Set-Mailbox -Identity <user> -RecipientLimits 0
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 clients to access. This solution is in lieu of disabling as outlined above.
Just like I stated about the steps yesterday, implementing the above steps are NOT instantaneous! It can take around 5-10 minutes for the disabling of the protocols and/or settings 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 notice that while we recommend setting –RecipientLimits on the mailbox, we do NOT mention setting the Send and Receive Quota settings. This is because the RecipientLimits changes go into effect very quickly whereas changing the Send and Receive Quota settings do not. While you can change the Send and Receive quotas as well, as it relates to this issue it is not a recommended workaround and won’t help in the short-term.
One option I did not mention yesterday, which is a workaround that works for ALL the connection methods (ActiveSync, OWA and Outlook) is to MOVE the mailbox. Not really a great option (especially if dealing with a very large mailbox and/or you have no place to move it to). But if the mailbox gets moved it causes all the existing connections to be reset (Note: this doesn't happen until the 2nd phase of the Online Mailbox Move process in Exchange 2010…it happens immediately with Exchange 2007 as Exchange 2007 does NOT have Online Mailbox Moves).
I’d be remiss to not mention another option related to web-based services (including ActiveSync) which would remove the caching impact is to bounce the IIS service (e.g. IISRESET), which clears all caches and reset all connections due to service restart. However, this would be required on ALL Exchange CAS servers possibly used and would impact many (if not all) users. Obviously, not a good solution…but in an urgent situation could be used and would go into effect the quickest.
A follow-up question I received is also whether changing the password on the AD account would help. The answer is, no. You may notice that after a user’s password is changed both the old and new password may work for some time and/or the new password doesn’t start working right away. This is because the old token, which was validated and gets cached (see above), is still considered valid and continues to work.
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.
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.
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-CASMailbox <user> | Select ActiveSyncAllowedDeviceIDs
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.
I recently was working with a customer in their process to convert their legacy Address Lists from LDAP (used by Exchange 2003) to OPATH (required by Exchange 2007/2010) and ran into an interesting find.
After using the LDAP to OPATH conversion script by Bill Long to generate and review the list, we started updating the Address List filters. The first few went fine...the converted fiter was tested, set, and then verified. The verification was to check that the RecipientFilter returned from the Get-AddressList command matched what we had entered via Set-AddressList. All was going fine, until about five Address Lists into our list when we noticied that the OPATH filter we entered had been changed...there were a TON more parenthesis in the filter than we had used!!!
Filter entered:
((Alias -ne $null) -and (customAttribute1 -eq "Contoso") -and (customAttribute2 -eq "Corporate") -and (((ObjectCategory -like "person") -and (ObjectClass -eq "user") -and -not (Database -ne $null) -and -not (ServerLegacyDN -ne $null)) -or ((ObjectCategory -like "person") -and (ObjectClass -eq "user") -and (recipientType -eq "UserMailbox")) -or ((ObjectCategory -like "person") -and (ObjectClass -eq "contact")) -or (ObjectCategory -like "group") -or (ObjectCategory -like "publicFolder") -or (ObjectCategory -like "msExchDynamicDistributionList")))
Filter returned:
((((((Alias -ne $null) -and (CustomAttribute1 -eq "Contoso"))) -and (CustomAttribute2-eq "Corporate"))) -and (((((((((((((((((ObjectCategory -like "person") -and (ObjectClass -eq "user"))) -and (-not(Database -ne $null)))) -and (-not(ServerLegacyDN -ne $null)))) -or (((((ObjectCategory -like "person") -and (ObjectClass -eq "user"))) -and (RecipientType -eq "UserMailbox"))))) -or (((ObjectCategory -like "person") -and (ObjectClass -eq "contact"))))) -or (ObjectCategory -like "group"))) -or (ObjectCategory -like "publicFolder"))) -or (ObjectCategory -like "msExchDynamicDistributionList"))))
NOTICE THE DIFFERENCE IN THE NUMBER OF PARENTHESIS!!!
The resulting filter worked fine, returning the same results as the originally specified filter, but we wondered if we had run into a bug...it seemed like all those extra parenthesis were NOT needed and might even make the filter inefficient!
After doing some research and going through TechNet articles and our bug database, it turns out this conversion is by design. The issue is that we had MULTIPLE conditions all being evaluated together:
( (Condition1) -and (Condition2) -and (Condition3) )
When the above gets parsed by PowerShell, the resulting filter will be changed and become:
( ( ( Condition1 ) -and ( Condition2) ) -and ( Condition3 ) ) )
This way when evaluated, only 2 conditions are checked at a time. In this case, it validates that Condition1 and Condition2 are both true. Then it moves on and checks that the result of that test and Condition3 are true.
Again, this is NOT a bug but BY DESIGN. It just looks wrong (especially if you have several items like this) as though something just decided to add a bunch of parenthesis for no good reason.
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.
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.
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".
When you receive and click on a meeting request to join a Lync-based meeting, If you have Lync Client 2010 installed it will be used to join that meeting. What if there's a problem joining the conference using the Lync thick client (there are scenarios where it may not work if there are problems with the company hosting the Lync meeting's Federation setup, etc). Or, maybe you just want to join the meeting and use the Lync Web App instead of the Lync thick client?
Unfortunately, there's no button you can click to do this...and if you're using IE8 and above, the IE window quickly closes after you click on the link in your email so that you can't access the "Use Lync Web App" link.
However, there is a way to force the use of Lync Web App.
To force connecting to a Lync meeting using the Lync Web App instead of the Lync thick client, do the following:
For example, if the URL to join the Lync meeting given is:
https://meet.contoso.com/john.smith/ZR2RJ141
Change it to:
https://meet.contoso.com/john.smith/ZR2RJ141?SL=1