CertificationsCategoriesLast web search to here |
Tuesday, April 21. 2009Demystifying the Office Communicator 2007 R2 Client Auto-Update feature and how to setup it upComments
Display comments as
(Linear | Threaded)
Wow, amazing! You should get the money that was paid the guys who wrote the OCS docu.
You know what - that is one of the best comments I've ever received on this website. This really made my day. I really appreciate that!
I had a bit of a bad day and a horrible migraine - so, thank you!
I have found the msp file, but I am wondering about this folder that the clients pull from. I don't see the \\autoupdate share anywhere on the system, and when i browse IIS there is no OC folder under the Autoupdate/Int/Files folder. Do I need to manually add this folder structure in IIS and on the front-end?
Hopefully I'm missing something simple... Thanks, Paul
I guess I might have been vague in my post, but yes, you need to manually create the "OC" directory if you decide to mimic my setup. It doesn't exist by default.
I tried to leave it blank to see what it would do - but the version editor didn't let me do it.
Just to clarify, if you are on a Standard Edition server, %ProgramFiles%\Microsoft Office Communications Server 2007 R2\Web Components\AutoUpdate\Files\ already exists, but %ProgramFiles%\Microsoft Office Communications Server 2007 R2\Web Components\AutoUpdate\Files\OC\x32\fre\1033\ does not.. so you need to manually create that directory tree structure for it to work. Easiest way it to browse into the Files directory and just create the folders under there.
Good stuff. Hopefully we'll see some official documentation around this in the future, but in the meantime this is by far the best info around the AutoUpdate feature for MOC.
I guess I'm in a bit of a dilemma - I placed the share for the updates on a different server and cannot for the life of me get this to work. This is for an enterprise server.
Ricardo: So true. Does the OCS documentation even include any of the auto update docs? All I saw was something along the lines of "point it at your share"
I solved my issue after going over this again - I created OC manually because you can't apparently point it to the root of the share. ba bing!
Just wanted to say thanks! This is a great blog and has been very helpful!
I wish that were the case but I don't believe so. It would be great if it were included.
Just wanted to post and see if anyone else saw this issue or would have any input...
Internally this is working great, external users are failing to download the update. However if I have those same users browse to the full URL from a web browser it prompts them for credentials and then prompts them to download. The only 3 people I have tested with are not on the domain, am trying to test with a domain machine and see if it has something to do with that. I would assume it would use the already provided credentials in communicator to authenticate though, any ideas? -_Randy
It might be how you are publishing your reverse proxy for authentication passthru.
When I do a request externally from a non-domain joined computer using a web browser, I will get an authentication prompt for credentials. As long as I enter in a proper password, it sends me the file. If I abort out of the handshake, it gives me 401 access denied. If I update the non-domain joined clients externally, I only get prompted for admin elevation - I don't get prompted for passwords.
I tested this on a standard edition, and you don't need to have the \\..\Update share, Communicator will download the update thru http.
I my case the IIS log is showing Remote Access: 2009-04-04 19:10:57 W3SVC1 172.20.20.20 GET /AutoUpdate/Ext/Files/OC.3.5.6907.9/x32/fre/1033/communicator.msp - 443 domain\user 172.20.20.1 Microsoft+BITS/7.0 206 0 0 Internal: 2009-04-28 21:10:57 W3SVC1 172.18.0.137 GET /AutoUpdate/Int/Files/OC.3.5.6907.9/x32/fre/1033/communicator.msp - 443 inceptio\sg 172.18.0.25 Microsoft+BITS/7.0 206 0 0
Correct. Only Enterprise Edition cares about/uses the \\servername\share\ architecture due to it being a pool of servers and not a Standard Edition server.
I tried to word it as carefully as I could, but it is definitely a confusing aspect of the whole thing.
Just a note to let others know I started having Address Book issues after setting up the SPN on the pool. I found this article http://communicationsserverteam.com/archive/2007/12/17/52.aspx that discusses this and specifically states:
The issue is that it should not be using Kerberos as the name pool02.domain.local is only virtual and should not by default have a service principal name (SPN). In this case the SPN was registered and when the Kerberos ticket request went to the domain controller the client was issued a ticket. The issue was resolved by using SETSPN.EXE to remove the additional service principal name from the computer account. In my case I removed the SPN and it resolved the issue with the address book but of course I do not have working automatic updates. Just an FYI in case someone else has an issue after adding the additional SPN for an enterprise pool.
Hi,
I have been having fun with this for a day or so. There is a reskit tool for "publishing" the patches, it created the directory trees needed. Although I have run into an issue and the only solution I can find is to turn on anonymous access to the language (1033) directory for the "int" tree. If I try to update externally I get prompted to for my domain password, which once entered the download continue without issue (this appears to be a prompt triggered for the BITS download). After this the IIS logs show a username against the BITS log entries. If I try to update internally I get prompted for a password, and get into a continuous loop which never ends. Has anyone come across a similar issue? Adam
Just a point for people trying to do some versioning of their communicator patches. That doesn't seem to work well.
I've tried the following: OC.3.5.6907.9 OC OC_3_5_6907_9 OC3569079 Only OC worked for me.
Great post and very helpful...
But the updates only seem to work properly if the end user is configured as local administrator on their computer. This is definatley not the case in most corporate environments. We need a solution that works for non-admins or the patches should be applied using WSUS. John
Hi Aaron,
Great information! Once Communicator downloads the .msp file, what context does it use to actually install it? This feature is only useful if Communicator is able to use the local SYSTEM account to perform the installation. If the patch installation runs as the end user then this feature is useless - it would be very unusal for the end user to have the administrator rights required for the installation. Cheers, David
Comment: using UNC path is not recommended when firewalls isolate the OCS pool from its clients. Windows file share are known to be security holes.
Hi,
Thanks you for your post, I have a issue with the download files, in fact when I tape on my browser https://pool/AutoUpdate/Ext/Files/OC/x32/fre/1033/communicator.msp I can download it But when I put https://pool.domain.com/AutoUpdate/Ext/Files/OC/x32/fre/1033/communicator.msp An authentification windows appears (login and password) From the IIS log 401 1 0 From the client OC I see the start downloading but an error mesage appears How I modifiy the path of communicator download ? Or What do I need change to work perfectly Thks in advance
Hi,
I have a message from my communicator "OC attempted to download an update, but the file does not exist on the server. Your system administrator will need to update the file or location before an update will be availaible " I can download the file from https://pool/AutoUpdate/Ext/Files/OC/x32/fre/1033/communicator.msp But not from https://pool.domain.com/AutoUpdate/Ext/Files/OC/x32/fre/1033/communicator.msp Someone have an idea to fixe my issue ? Regards,
Slightly different take on this problem. My users are not administrators on their workstations and cannot install updates. I don't want them to be able to check the Tools, Options, Alerts, Automatic Updates check box.
Support tells me their is no way to disable this option and hopefully it will be in a product enhancement - which I requested - and controllable via the standard MOC ADM file. The answer is to make a custom ADM file like below. When working with custom ADM files make sure you uncheck "Only show policy settings that can be fully managed" in the Group Policy Object Editor, View menu, Filtering... dialog each time you reopen the editor. Here's the ADM that worked for me: CLASS USER CATEGORY "Microsoft Office Communicator Policy Settings" CATEGORY "PNHS MOC User Updates" POLICY !!POLICYText EXPLAIN !!EXPLAINText KEYNAME "Software\Microsoft\Communicator" SUPPORTED !!SupportedMOC VALUENAME "AutoUpdatesOn" VALUEON NUMERIC 0 VALUEOFF NUMERIC 1 END POLICY END CATEGORY END CATEGORY [strings] EXPLAINText="Set MOC, Tools, Options..., Alerts, Automatic Updates on or off. Users at PNHS do not have the ability to update their client therefore the option is set to disable which set the registry value to zero." POLICYText="Disable MOC Tools Options Alerts Auto Updates" SupportedMOC="Communicator Version 3.5.6907.83"
Using your instructions (which were fantastic by the way!) my external OC clients are getting the update. Problem is when they try to install the update I get the error that the upgrade patch cannot be installed by the Windows Installer service because the program to be upgraded may be missing, etc, etc. This is due to the fact that OC is running as Standard User, therefore it can't install the update.
All our users are non-domain joined computers. Do you know of any solution to this issue? Honestly it seems quite stupid that even though the local user is a local admin, Communicator doesn't prompt to elevate the permissions to install, it just fails. Any ideas on how to fix this issue?
So yeah, I'm an idiot. I added the Attendant Console MSP file to the same folder as the OC MSP update thinking maybe I would be lucky and attendant clients would also automatically update. I guessed wrong. Instead, it was pushing out the attendantconsole.msp file instead of the Communicator.msp file out to the clients, thus the error. I deleted the Attendant Console file and it worked perfectly.
Any idea how to make this work for the Attendant Console? I didn't see an AC option in the client filter.
Dear Aaron:
If I want to use the Client Version Filter to block someone client verion not all user. Do u know How to do? or is it possible? many thanks Jason
I used to get this thing working. Recently i am getting errors stating that the update file is not in place. This is third client filter i am applying. Do you guys think it might be the reason ? since i have other communicator.msp files in the same location i rename the files. Any suggestions ?
Just wanted to add another huge THANK YOU!!! for writing this post. I had been searching for two days trying to figure out how to get this to work and through the hundreds (or thousands) of pages of documentation for the product. Your write up is right on the money and so very much appreciated!
|
Search this blogLinks
My e-mail address
Exchange: Hotfix Tracker (All products) OCS: OCS 2007 R2 Documentation Collection Office: Office Cumulative Updates Site Windows: Other: FriendFeedTranslate this pageCalendar
Creative Commons Restrictions |
In OCS 2007 R2 it is fairly easy to block certain clients from connecting to OCS, just like in OCS 2007
Tracked: Jun 30, 11:23
Tracked: Sep 11, 13:04