We normally add the following Help and Training site to IIS as a value-add on our Lync engagements but recently there was a requirement for a customer to have a look at the material before we were engaged.
As such I published the site so they could have a look externally without having to bother installing any fiddly bits themselves.
Feel free to take a look.
https://host.risual.com/helptraining
Good luck
NeilC
Came across this handy utility the other day and whilst I still prefer to use my own scripts this tool is really useful for getting all the normalisation rules and routes etc. configured quickly.
http://lync.buchanan.com/LyncOptimizer/
Have a go and see what you think.
Good luck.
NeilC
This is most definitely worth reading for anyone that is considering implementing a stub based archiving solution against Exchange2010:
http://blogs.technet.com/b/jamec/archive/2011/08/01/exchange-2010-database-page-fragmentation-caused-by-archive-solutions.aspx
Good luck
NeilC
An interesting read from the General Manager of the Exchange Team at MS:
The Exchange Sustained Engineering team recently made the decision to recall the June 22, 2011 release of Exchange 2010 SP1 Rollup 4. This was not an action we took lightly and we understand how disruptive this was to customers. We would like to provide you with some details that will give you a deeper understanding of what actually happened and, more importantly, what improvements we are making to prevent this in the future.
-
Q: What actually triggered the recall?
A: While fixing a bug that prevented deleted public folders from being recovered, we exposed an untested set of conditions with the Outlook client. When moving or copying a folder, Outlook passes a flag on a remote procedure call that instructs the Information Store to open deleted items which haven’t been purged. Our fix inadvertently caused the RPC to skip all content that wasn’t marked for deletion because we were not expecting this flag on the call from Outlook on the copy and move operations.
-
Q: Why didn’t you test this scenario?
A: The short answer is we thought we did. We didn’t realize we missed a key interaction between Exchange and Outlook. The Exchange team has well over 100,000 automated tests that we use to validate our product before we ship it. With the richness and number of scenarios and behaviors that Exchange supports, automated testing is the only scalable solution. We execute these tests in varying scenarios and conditions repeatedly before we release the software to our customers. We also supplement these tests with manual validation where necessary. The downside of our tests is that they primarily exercise the interfaces we expose and are designed around our specifications. They do test positive and negative conditions to catch unexpected behavior and we did execute numerous folder copy and move tests against the modified code which all passed. What we did not realize is that our tests were not emulating the procedure call as executed by Outlook.
-
Q: Exchange has been around a while, why did this happen now?
A: In Exchange 2010 we introduced a feature called RPC Client Access. This functionality is responsible for serving as the MAPI endpoint for Outlook clients. It allowed us to abstract client connections away from the Information Store (on Mailbox servers) and cause all Outlook clients to connect to the RPC Client Access service.
As part of our investigation, we discovered that there was some specific code added to the Exchange 2003 Information Store to handle the procedure call from Outlook using the extra flag. This code was also carried forward into Exchange 2007. But when the Exchange team added the RPC Client Access service to Exchange 2010, that code was not incorporated into the RPC Client Access service because it was mistakenly believed to be legacy Outlook behavior that was no longer required. That, unfortunately, turned out not to be the case. The fact that we were not allowing a deleted public folder to be recovered was masking this new bug completely.
-
Q: Are there other similar issues lurking in RPC Client Access?
A: We do not believe so. The RPC Client Access functionality has been well-tested at scale and proven to be reliable for the millions of mailboxes hosted in on-premises deployment and in our own Office 365 and Live@EDU services.
-
Q: What are you doing to prevent similar things from happening in the future?
A: We have conducted a top-to-bottom review of the process we use to triage, develop and validate changes for Rollups and Service Packs and are making several improvements. We have changed the way we evaluate a customer requested fix to ensure that we more accurately identify the risk and usage scenarios that must be validated for a given fix. Recognizing the diversity of clients used to connect to Exchange, we are increasing our client driven test coverage to broaden the usage patterns validated prior to release. Most notably, we are working even closer with our counterparts in Outlook to use their automated test coverage against each of our releases as well. We are also looking to increase coverage for other clients as well.
Kevin Allison
General Manager
Exchange Customer Experience
Microsoft have released a new CU for Lync Server and client as of July 23rd 2011.
Links as per below:
Server: http://support.microsoft.com/kb/2571546
Client: http://support.microsoft.com/kb/2571543
Good luck
NeilC
Had an issue at a customer whereby the AA would not forward key mappings to an extension number although it would work if you browsed the directory on the AA and entered it there… annoying.
Found this really useful blog which saved me some valuable time so thought I would re-blog it.
http://ucmadeeasy.wordpress.com/2010/08/29/exchange-um-auto-attendant-key-mappings-not-transferring-calls-after-sp1/
Thanks
NeilC
I have come across a number of issues recently where when installing Lync or Exchange on a virtual server it has continually prompted for restarts.
In Lync this has always been at the point that the SQL database is installed for SE; it usually restarts then picks up the install and continues but in this instance it would restart and after several minutes request another restart and so it goes on.
In Exchange it occurred as part of the readiness checks; it would report an outstanding restart was required, irrespective of how many times the server was rebooted.
The issue seems to be caused by the ‘PendingFileRenameOperations’ registry key.
Normally this field would be cleared down on restart but this wasn’t happening.
The fix?
Browse: HKLM>System>CurrentControlSet001>SessionManager
and delete the entries in the ‘PendFileRenameOperations’
Good luck
NeilC
Whilst running the SSRS on the Archive/ Monitoring Server I was getting the following error:
an error occurred when deploying monitoring server reports.
an underlying connection was closed.
an unexpected error occurred on send
The fix for me was to remove all binding from the Web Services URL and Report Manager URL in the Reporting Services Configuration Manager and then to add back only the HTTPS binding against both IP4 and IP6.
Hope this saves you my head-ache.
NeilC
