The rollup is available on the Download Center here:
It will be available on Microsoft Update in 2-3 weeks from now (we will announce that). In case that you need a fix in a language that is not available right now, they are in the pipeline already so please check back.
The KB article describing this release as well as fixes is here: http://support.microsoft.com/?kbid=953467
We specifically want to call out two things fixed regarding the overall installation experience:
1) Service startup issue as described in KB http://support.microsoft.com/kb/944752 as well as our previous blog post.
The rollup installer will now make the required modifications to the config files, even create new config files if not found. If customers have already modified the config files and have a generatePublisherEvidence setting, it will be left intact. Note that you still need the right version of .NET (see KB 944752) for the fix to take effect.
Un-installation of the rollup will not rollback the addition of generatePublisherEvidence to config files.
2) Blank OWA logon page after installation of rollups 3 and 4, if you have modified logon.aspx file
The rollup installer will now overwrite any OWA script files if required to ensure proper operation of OWA. You will need to redo any customization after installation of the rollup.
Here is the final part of these posts, we will talk about configuring the CCM/Tandberg to work all together, this will let you leverage the conferencing capability from any phone anywhere, it is cool and very important and I found that most of the Tandberg customers don’t know about it.
To make it works, make sure to do the following steps at the 4200 MCU:
- From the Gateway menu, add a new gateway, type in the IP of the Cisco Call manager.
And you are done J.
From the Cisco Call manager, follow the below steps:
- Add the MCU as a gateway.
- From the routing plans, add a new route pattern, this will match a number (for example 1000) and route this pattern using the gateway you just configured.
Using the above if a user internally calls 1000, he will be prompted with the Codian MCU autoattendant, the 1000 extension should be reachable from the outside using either digits manipulation..etc so users from the external telephone network can dial that number.
No users in the OCS can add the conference ID as a user and call that user, also call from the phone the MCU and amazingly they can hear users from the Video Conference points and on the OC clients.
Yesterday was one of those rare days, one of those where I spent 7 hours staring to my screen trying to push couple of server to work, the problem started at 11 AM and solved by 7 PM, but the trick was in finding the problem.
Briefly the problem located in specific servers in a branch of mine, the damn servers didn’t want to become a domain controller no matter what I did, the problem that the SYSVOL folder didn’t want to replicate between server in HQ and server in the branch, below what was happening:
When I launched the Domain controller installation wizard, everything went nice, to complete the installation a restart is required and a replication of the SYSVOL folder (where group policies and domain settings resides) has to be completed after the restart, this normally takes 15 minutes, tracing the SYSVOL replication I found that the replication stops at 14 MB of the SYSVOL (it is about 120 MB), well this is normal.
Recycle the SYSVOL replication, 13.8 MB.
Check the SYSVOL replication scope using ntfrsutil seems right, push it using the command line, 13.6 MB.
Well, this is becoming weird, so let us bring the army. Tracing the Filesystem activity using Filmon and process explorer and…..ok I saw that the FRS.exe cannot have access to the replication delta files after it reaches 13 MB, it gives me “Access is denied or file cannot be found”.
It is ok, using the burflag registry key I can rebuild the hall SYSVOL, trying that and silly me; it is 20 MB
Fine, let us skip the first server, let us bring the other server, now guess what, cannot exceed 25.5, first round 25.6, second round 25.4 third round 24.7, using filemon and PE I found the same output “Access is denied”.
Now it is time to know exactly why access is denied, doing advanced logging for the FRS, I found that transactional log files exist, but the FRS cannot read and write from it, doing a performance monitoing for the disk level read/writes I found that it gets so slow when a big chunk of log file gets replicated to SYSVOL temp. folder, doing a Memory trace for the handles using handle……wolla!!!!!!!!!! It is the KASPESKY.
The avp.exe process was scanning the a big log file (it is about 30 MB in size), the scanning takes so much time to complete, the scanning windows was bigger than the SYSVOL replication timeout windows this is a known bug here , so it times out and keeps retrying. And failing at the same file. So a very small registry key stopped my Servers to be come on line, what a mess?!
I checked the Kaspersky policy, I found the SYSVOL folder was excluded from the scan, but not the subfolders, added them and now I am able to run the SYSVOL replication. A smart one will say why this didn’t occur in HQ, as far as I can see this is because of HQ runs at 4 GB of RAM.
I have been working on this for 2 weeks now, I have upgraded my MCU from 2.3 to 2.4, this “as Tandberg” allows me to use NTLM authentication rather than anonymous authentication for MCU registration, but it didn’t work.
For some reason the MCU cannot obtain the GRUU that is returned from the OCS and cannot register itself in OCS, I believe that this is a bug in OCS (as far as I can see) because the OCS is using some SIP extension that has make my life harder before, I am working with Tandberg folks on it now.
So keep your MCU at 2.3 until further notice.