01 Maret 2012 17:01
I've just upgraded from VS11 Dev Preview to VS11 Beta (uninstalled the former before installed the latter).
I see a number of help "chapters" in the "Manage Content" window that need updating, and some new I want to install.
When I click the "Update" button I am prompted for my credentials, then I see "Connecting to Help Content Manager...", then...
01 Maret 2012 17:40
There should be a status on the bottom left of the UI indicating there was an error combined with a link that will show the error information.
If you still have the UI running that information hopefully can help figure out what is happening. If you have closed the UI the error should also be in the event log.
Out of curiosity, when the elevation dialog appears are you using the account you signed in with or do you have a separate administrator account? The reason I ask is we cannot do content download from a impersonated account (e.g. if the logged on user is different from the user running the process). That would cause a behavior similar to what you are describing. If you can get the error information we should be able to help get content to install.
02 Maret 2012 8:14
The bottom left of the UI just says "Connecting to Help Content Manager...", then reverts to "Ready" after some time.
The application log contains:
- System - Provider [ HlpCtntMgr - EventID 1003 [ 0 Level 2 Task 1 Keywords 0x80000000000000 - TimeCreated [ 2012-03-02T08:08:01.000000000Z EventRecordID 91740 Channel Application Computer SBA1033.rd.ocecreteil.oce.net Security - EventData
Help Content Manager exited with error:
And yes, I am using the current user' credentials -- why can't that be seamless BTW? It's weird that one has to provide his own credentials...
02 Maret 2012 14:42
I suggest you try it several times.
I had the same issue 2 - 3 times, but then I got a connection and all the requested packages downloaded correctly (albeit, slowly).
It may be a server congestion issue with all the people installing VS 11 beta, then updating local help.
02 Maret 2012 14:44
Tried it quite a number of times here at work.
At home I have no proxy ;-) (also no domain and no IT...) and it worked like a charm on first try...
02 Maret 2012 17:36
From the error help content manager failed to elevate to administrator. In general this should not be happening. If your user account is not an administrator when we attempt to elevate you should be given an error saying you do not have sufficient privileges.
I am trying to reproduce the issue you are seeing so that I can hopefully find some way to work around it. Do you mind giving me some more details about your system?
1) What operating system are you using?
2) Is your machine joined to a domain?
3) Is your user account an administrator on the local machine?
4) What UAC level is set on your machine?
UAC level can be found on the control panel under "Change User Account Control settings". For at least windows 7 it is a list of 4 options starting with "Always notify" and ending in "Never notify"
05 Maret 2012 9:10
1) 64-bit Windows 7 Pro
2) yes the machine is joined to a domain
3) no my (domain) user account is not part of the local administrators group (nor of the domain admins group)
4) UAC is set to "always notify"
05 Maret 2012 17:08
Thank you for the details. I will look at this however content management requires the account doing the management to be local administrator.
Is there an administrator account you can use to install the content?
07 Maret 2012 9:00
Yes there is an account available, even though this is an exception to our official IT policy (developers don't have admin accounts).
Just tested it, and it works, but IMVHO that needs to be fixed for at least the following reasons:
- admin rights should not be needed to install documentation updates (see above policy issue)
- this is a regression compared to VS2010, where anyone in the HelpLibraryUpdaters was able to install updates
- one has to do a full logon using the admin account, this cannot be done from the non-admin "dev" account even if you have the admin's credentials.
- IT doesn't want to be bothered every time the app says "update available"
05 Juni 2012 16:44
You didn't comment on my previous reply...
I want to mention that the problem is still there in Visual 2012 RC, and my earlier statements still hold...
05 Juni 2012 21:02
I apologize for not getting back to you on this. Yes this is a change between VS2010 and dev11 for content install. Unfortunately I do not have a solution for you other than to confirm that this is different.
The problem is that the content store is shared for all users and content consists of more than just text. The potential to include behaviors, scripts, etc. into content that could be left as a "sleeper" for future users/administrators to execute has made our security model more complex that I really like.
In VS 2010 our security model to handle this was to allow for administrators to delegate content install of certain types of content. The fact that only some content was allowed to be installed by non-administrators caused a lot of confusion and the general feedback we got was that you had to be administrator to install content since 3'rd party content was shipped in formats that we could not validate (e.g. MSHC files instead of signed CABs).
For Dev 11 we have followed that feedback and now require all content install to be done from administrator. We also tried to take a look at the different enterprise deployment scenarios. The deployment you might want to work with IT department on would be to have a single content store on a UNC path that all instances of VS on your network use. That would allow for them to update once for the network. Alternatly the update can be scripted as a command line and pushed to machines in a similar method as any MSI install.
If this is going to be a problem (e.g. your IT department cannot/will not manage content) please file a connect bug to have us re-evaluate our requirements. Also post the link to this thread so others can vote on it.
I wish I had more help,
06 Juni 2012 7:33
Thx for the feedback.
I don't understand everything ;-( from the rationale for the change, but I do understand you won't "fix that."
About your two suggestions:
- storing stuff on a share sounds like looking for trouble for me. We have experimented that to share SysInternals binaries around, but every time the updater run and some user has an open handle on one of the files, the updater fails and our NAS turns the file into a zombie that no one can open even for reading. I fear we would get the same thing if IT would update the help share while someone has the Help Viewer open. Am I right? If not, 1) why? 2) can you elaborate on how to a) tell Help Viewer to get content from a UNC path b) update the contents of the share?
- scripting the update of the local help content store: how would that be done?
06 Juni 2012 20:06
The administrator's guide (http://msdn.microsoft.com/en-us/library/hh492077(v=vs.110).aspx) was written to be a reference guide for these types of problems. I'll do my best to cover your questions but if I miss something it might help.
For network share:
The content store location is stored in a registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Help\v2.0\Catalogs\VisualStudio11\LocationPath for dev11). During scripted deployment of VS our expectation is that the store will be moved if desired. Doing this allows for an IT department to pick a standard location for help either on the machine or on a UNC path. For UNC we do advise having only one machine/user do the content administration however multiple machines can view content while this occurs.
There is always a risk of having the issue you describe, this could occur either on a local machine with multiple users or on a share. The network does add complexity that increases the chances. We tried to minimize the risk but I cannot guarantee you will never see the issue.
Here is what we are doing for content install:
When we install/update content the operation occurs in a separate folder from the normal content store. The last step of install is to move the files to the store. These files are versioned so there should be no collision with current files. Once the move is complete HlpCtntMgr raises an install complete message and goes idle for a few seconds so the viewers can reconnect and load the new files. After this idle time the previous files are deleted. If a file is still locked we leave it in place, all files that should be deleted will have a ".delete." file added to the content store subsequent content management runs will attempt to delete the file as well so eventually the lock should be gone and the file will be deleted.
All content install is done from HelpCtntMgr.exe; this application takes command line switches. One of the possible operations is "refresh" that will check for updates against the endpoint and install them if available.
06 Juni 2012 20:25
Thx Jason for the detailed information.
I forgot to mention one point: our Internet access infrastructure uses a proxy with authentication, I will need to check with IT whether they are able to run scripts in a context where this is disabled--otherwise such as script cannot run unattended. All I know is that they can disable the authentication for some URLs or domains.
13 Juni 2012 7:22
I have an add'l question on this topic.
Is there a mean to download all packages (or a subset) on a machine (typically: with a high-bandwidth Internet connection) and to deploy them on another machine (typically: with no Internet access or a low-bandwidth connection)?
13 Juni 2012 14:49
Yes. You should be able to copy the content store from one machine to another. In the administrators guide (http://msdn.microsoft.com/en-us/library/hh492077(v=vs.110).aspx) the section "Deploying Pre-Installed Local Help Content on Client Computers" describes this to some extent. The high level is that you install to one machine and copy the folder contents to another making sure to replace all files.
Let me know if that helps,
13 Juni 2012 14:54
Thx for the follow-up.
Sounds great! I will give this a shot.
P.S. I'm hoping that http://msdn.microsoft.com/en-us/library/ee855704.aspx will give me similar information for VS2010, 'cos it might be interesting e.g. for our IT to be able to mass-deploy the latest Help Content onto all desktops at once. If you have specific links about this, please share ;-)
14 Juni 2012 1:32Moderator
for VS 2010 I have notes here that may help...
Rob Chandler Help MVP http://Helpware.net/ http://mshcmigrate.helpmvp.com/
14 Juni 2012 6:54
Thx Rob. Will check this out.
28 Agustus 2012 11:18
This might not be (and probably isn't) the best place to report this, but... installing content from a normal developer account with the RTM bits just doesn't work.
First one is informed that admin privileges are needed to install content.
Then one has to answer two UAC prompts.
After that, clicking on the Update button yields an error, and "click here for details" displays:
Microsoft Help Viewer 2.0
The following errors occurred while performing the requested tasks:
An error occurred while updating content: Unable to update content. To install content from online, switch to the user account you used to log on to the computer, and try again.
I'm assuming installing content will work from a admin logon, but one shouldn't have to switch users / logoff for this!!!
28 Agustus 2012 16:37
I am assuming here that you are installing from online. With that assumption, the behavior you are seeing is expected.
We use the BITS service to download content. BITS has some odd behaviors around changing user credentials between the job being created and the logged on user (http://msdn.microsoft.com/en-us/library/windows/desktop/bb540464(v=vs.85).aspx). Basically if you force BITS to create the download job as another user the job will not start until that user logs in. This would not work for content install since after the download we still need to unpack and install the content we therefor let BITS fail to create the job instead and report the error.
I realize in general the experience we are providing you is not the one you want. I am hoping the steps I listed above are at least an acceptable way to work around the problems you are hitting. Even if the steps are working for you however I think my team needs to look at this for future releases. The best option I can think of to keep this on our radar is to have you either file a suggestion (http://visualstudio.uservoice.com/forums/121579-visual-studio) or a connect bug (http://connect.microsoft.com/VisualStudio). If you do either of these please respond back to this thread with a link so others that are following the thread can vote if they agree.
Sorry I cannot help more.
29 Agustus 2012 5:43
Thx for getting back to me on this.
I'm not sure what "steps [you] listed above" you are referring to. The shared UNC location populated and kept up-to-date by IT guys?
I will most probably file a Connect bug for this, at the very least 'cos I few the new situation as a regression vs. VS2010.
29 Agustus 2012 15:58
The UNC location. There is also in the admin guide the option to have either a folder copy style deployment with centralized management or command line deployment.
Please file a connect bug or suggestion. The feedback is very important.
30 Agustus 2012 7:24
30 Agustus 2012 19:10
Connect ticket already closed...