I use stsadm-o addsolution -filename "mySolution" to install a solution, but when the UAC(User Account Control) is enabled, a "Access Denied" exception will be thrown.
I want to know how to add a solution with UAC enabled?
Note: I cannot use runas administrator, for it's cannot be invoked by third assemblies.
Update: I just want to use C# to implement Runas Administrator.
thanks in advance.
I'm going to take a stab in the dark here - I'm guessing that when you say 'third assemblies', you're referring to a third party assembly that is running as part of some application, and you want that application / assembly to be able to install a sharepoint solution. I.e., you're building some type of sharepoint solution management tool.
I could be way off on that, as it's just a guess. But assuming that's true:
If you have UAC enabled, and you want this other assembly / application to be able to call stsadm, then you need to do run this other assembly / application as administrator. Right-click on the exe that kicks it off (or shift-right click), then click 'run as administrator'. That will cause the other application to run in the context of an administrator, so when it calls stsadm it should work.
Run command prompt as Adminstrator
after two days investigating, I have the final result.
In SharePoint 2010, I installed a solution named "NewsGator.Core.wsp", it's a third party solution. When it's installed, some assemblies will be deployed to GAC. When you retract the solution you must notice that if the assemblies are used by w3wp.exe or not(process monitor can do this, you should first run it as administrator), if so your retract job will failed. It occurs in UAC enabled environment and will succeed if you use runas administrator to execute retract method.
So, firstly I doubted it as permission issue, using runas administrator can just make it work, then I came to ask the question above, but finally I found the cause by process monitor, after ended w3wp.exe or iisreset I got my retract job complete with successful.
Hope the above can help you.
Thanks very much for all your help, best regards.
Related
i'm using vb.net 2010, .net framework 3.5 and the procedure and the exception I get, are as follows:
I've been reading about manifest, and this and that, but what it seems to me is that i'm still missing something, will anybody kindly give me any suggestions?
Thanks in advance!
You need to be elevated to modify this key. The process that performs these registry modifications needs to run as admin.
Use the requireAdministrator option in the manifest. Or start the process using the runas verb.
Does anyone know if I NEED To wrap my Office 2007, vsto-based add-in in a MSI? It seems to be a lot of extra overhead and headache, just to have it not work anyway.
When I do get it to install, I still need to run the vsto installer, even though I have tried to use the |vstolocal switch to keep the add-in's deployment centralized.
Has anyone pulled this kind of install off successfully?
I've deployed VSTO from SCCM without using an MSI.
The trick is a simple command line:
"%commonprogramfiles%/microsoft shared/VSTO/10.0/VSTOInstaller.exe" /i <path to vsto>
VSTOInstaller.exe [[/install ] | [/uninstall ]] [/silent]
[/help]
/install, /i: Install the solution. This option must be followed by
the fully qualified path of a deployment manifest in the form http://,
https://, or \servername\foldername.
/uninstall, /u: Uninstall the solution. This option must be followed
by the fully qualified path of a deployment manifest in the form
http://, https://, or \servername\foldername.
/silent, /s: Install or uninstall without prompting for input or
providing information.
/help, /?: Generate this help message.
EXAMPLE: VSTOInstaller.exe /i \servername\foldername\AddIn.vsto
Be aware that with the /silent option "trust for the addin has to be built into the project or it will default to 'don't install' when using the silent switch." (source: TechNet post)
I've tried it, and you don't need to wrap it in an MSI if you're happy for users to manually install it. If you:
use the publish tab in project -> properties
setup your "publishing folder location" and "installation folder URL" properly
set and all of the other meta-data properly, including stuff in your AssemblyInfo.cs file
whack the "publish now" button
share out the installation folder and email out the link
ensure that users have the right permissions to install it (local admin I guess, you'd need to check)
It worked for me. On Windows 7 and XP too.
The whole "this publisher is untrusted" thing is a complete mess, trying to fix that involves writing some really stupid code that tells Windows that "hey, by the way, I am actually trusted". I didn't bother and just told people to ignore the warning.
I'm guessing that you only need an MSI if you want to push out the add-in using active directory and do an automated install.
Environment: TeamCity 6.5.1 on Win2k3, BuildAgent(s) on Win2k3, Visual Studio 2k10, .NET v4, Nant 0.91
I'm completing the setup of TeamCity and am trying to lock down the BuildAgent account on the build machine(s) per our security guidelines. The build is crashing the first time "devenv.exe /build" is called via the Nant script:
Faulting application devenv.exe, version 10.0.30319.1, stamp 4ba1fab3,
faulting module msenv.dll, version 10.0.30319.1, stamp 4ba1fd94,
debug? 0, fault address 0x0000c36b.
I had no luck googling that message. However, if I change the BuildAgent Service from the Local Network Account to the Administrator account, things work. However, if I use another domain account, it fails. Also fails if I add that domain account to the local Administrators group.
Any ideas on what I'm missing? Is there a specific privilege you need to have in order for a "DevEnv /build" to work without crashing?
Yuck, I just went through this recently. First, use devenv.com, not devenv.exe. The devenv with the com extension can build a solution and send all output to the console, without using the gui. As the TeamCity agent is a service, it may not be allowed to interact with the gui at all.
Second, and I realize that this might not be possible for you (especially if you are building an MSI), but consider doing whatever you need to do to use the built in Visual Studio build runner that comes with TeamCity. It does utilize MSBuild to do its work. If you go this route and you still need devenv, then go find MSBuild Extensions Pack, which has already solved a lot of these issues with their own devenv build task.
Honestly, I ended up replacing Microsoft's installation projects with alternatives (InstallShield or WiX), and never looked back.
I am trying to execute a console application which updates creation dates on specified items in sharepoint lists.
When I try to execute I get this error:
There has been blocked for additions to the site. Contact system administrator to solve the problem.
I then went to the Central Administration to check if Quotas and Locks was set to Not Locked. Then afterwards running the stsadm commando
stsadm -o getsitelock -url http://mysite
Which returned SiteLock Lock="none", so those 2 matched.
I have debugged the console application and made it console.writeline each step it takes and it gets to the item.update(); part and that's when I get the above message.
Do you guys know another way around to solve this issue?
Have you gone through all solutions provided here ?
or
check the document library settings and found out that doc. library was set NOT to require check out although versioning was enabled. just try to set to require check out
i dont know this is the right solution but i have faced the same problem and i did restart my machine and the problem is resolved.
hope this trick work for you.
Check if your database read-only.
Folks,
I've got a strange issue at the moment with a visual studio 2010 built MSI...
When I run the msi, it performs a few tasks, then executes a tool we built - this tool then carries out some more advanced work we couldn't do within a custom task.
The issue here, is then when the msi starts my custom built tool, it doesn't execute it with the same credentials as I start the MSI with (i.e. my administrative login).
Is there a parameter I can pass to an MSI to enforece this? Or perhaps I can pass the credentials to the process when I start it?
My process is started using Process process = Process.Start(procInfo) nothing fancy. I've also noted the ability to pass in a parameterised username/password/domain, but this will vary depending on the user who is installing - can this be extracted from the installer somehow?
Any help (or questions) welcomed.
Dave
EDIT: for clarity... I'm running the MSI under my domain account, and I want my custom process to run under that 'context'. At present, it starts (regardless of whether I start as administrator or not) under the SYSTEM account (rather than mydomain\me). I'm using Windows Server DataCenter edition if that helps...
I should also add, I think this is a policy issue, but I've no idea what to check/where to check...
By default Windows Installer runs custom actions as the current user. If the MSI is elevated, custom actions will run as the elevated user.
Please note that if you are running the MSI as an Administrator, it doesn't mean your custom actions will have full Administrator privileges. On Vista or higher any user can gain Administrator privileges through elevation.
So if your custom actions need Administrator privileges, make sure they use the msidbCustomActionTypeNoImpersonate flag so they run under the local system account.
If this is not the problem and you just need access to the current user data, can you please give me more details?