I have created an agent iin which I call a dll file so that I can get data from another system eventually..
When I manually run this agent then the call to the dll file works and I get data from it.
When I call this agent from a browser then I get:
Error Description : Cannot create automation object
The security of the agent is on 3.Allow restricted operations with full administration rights.
Any idea why I get Cannot create automation object when running agent from browser?
When you start the agent from browser then the agent runs on Domino server.
So, you need to install automation object's software on this server.
When you manually run the agent then the code is executed on your client. This works because you installed the software necessary for creating the automation object on your client.
I found the same error but in my case everything was working properly until we restored a backup of Windows. The issue was caused because Office had to be reactivated again.
Sometimes this happens too because a corruption of the Word document, so you have to rebuild it.
I hope this could be helpful in future to other people
Related
We have a process which needs to work with a series of Excel (sigh) files.
The setup is:
SQL agent job run as a SSIS proxy account.
Calls SSIS package on a share on the server.
Which then starts accessing these excel files using the ACE driver.
The process will work under my credentials.
The process will work under other people's credentials.
The process will work in debug mode (although this is not a fair test
as that would use my local machine's driver)
The process will not work using the SSIS proxy account.
The process WILL work if I make the SSIS proxy account an
administrator on the server.
I have ruled out the following:
access to the files share. The account can load text files from
there.
32bit/64bit issues. The account CAN run given sufficient
permissions.
My opinion is that the service account needs some sort of level of permission to be able to use the driver. I can't work out what though.
I have tried LOCAL SECURITY POLICY option "Load and unload device drivers" with no success. ( I did think this had done it, but then realised that I had left the account in the admin group :-( )
Finally, the error message in question:
SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER.
The AcquireConnection method call to the connection manager
"TPR_ReadReportsExcelConnection" failed with error code 0xC0202009.
There may be error messages posted before this with more information
on why the AcquireConnection method call failed.
This seems to be beyond the supported scope depending on how you've set up your SSIS proxy account. See Additional Information section here. Not enough points to post an image so here is the important sentence:
provided the SSIS jobs run in the context of a logged-on user with a valid HKEY_CURRENT_USER registry hive
I have an issue when i execute my app.exe, there is an error which is revealed only in the ".exe", if i try todo the same thing when i use the sources, there is no problem, i think the problem is when there is a call of the update method from a datastore, it return -1 with generated .exe and 0 when i execute sources.
i have tried to refresh any library from my app, before building, but the issue remains, for information the app is using a DB2 DATABASE, and it is built and run in a windows7 environment.
The likely cause is that when you built the exe, the DataWindow object assigned to the DataStore wasn't included. You need to use a .pbr file in the Project object. Look in the help file under 'deploying your application'.
I have encountered this problem as well when I deployed strictly to a *.exe file. The problem went away when I deployed to a *.exe with a *.pbd. This is established on the "libraries" tab of your project by checking the pbd checkbox.
An 'exe' only deployment can't handle hard coded 'literal strings' in your code. Creating and deploying 'pbd' library will allow 'literal strings'.
I'm currently working on automating a powershell script to make a dump of a small DB.
The database is accessible through a company Sharepoint and I am leveraging an IQY file exported from said Sharepoint to read the database contents.
When I run the script manually (i.e. calling it from the command line), it works with no issues, but when I try and start the script from Task Scheduler, the following exception is raised:
System.Reflection.TargetInvocationException
the line that is generating the exception is:
$iqy = $xl.Workbooks.Open($query, 2, $true)
Where $xl is a new Excel.Application ComObject, created correctly and $query is a string containing the full file path of the iqy file.
As for my configuration, I'm trying to run my script on a Windows Server 2008R2, using a local administrator user (same user that is supposed to launch the scheduled script), which is also authorized to access the Sharepoint. I'm running Powershell 3.0. I'm not loading any Sharepoint-related snapins.
The only answers I found poking around hinted at granting "Trust" to the IQY file location and the Sharepoint itself in Excel. That did not help.
The Exception also seems to point at a sharepoint issue, but since the script runs fine when started manually, I cannot understand how it could be anything to do with Sharepoint.
Am I missing some intricacy of the Task Scheduler?
Any help would be greatly appreciated.
Never mind, I seem to have found an answer.
If anyone is encountering the same issue, it appear the Excel Com Object has a bug that does not allow it to run from the Task Scheduler if you set it to run regardless of whether the user is logged in.
To circumvent that create the following 2 folders on the machine where the script is supposed to run:
(32Bit, always)
C:\Windows\System32\config\systemprofile\Dektop
(64Bit)
C:\Windows\SysWOW64\config\systemprofile\Desktop
After creating the folders, it worked as expected.
Source: http://social.technet.microsoft.com/Forums/windowsserver/en-US/aede572b-4c1f-4729-bc9d-899fed5fad02/run-powershell-script-as-scheduled-task-that-uses-excel-com-object?forum=winserverpowershell
Our Sharepoint 2013 Application failed to install and is stuck in a odd state. I followed the recommended approach for deleting the application using powershell commands on the hosted Sharepoint server, but it doesn't execute properly.
Visual Studio Deployment/Retract Reports:
Skipping the uninstall step because the app for SharePoint is in an invalid state and cannot be uninstalled.
PowerShell Commands
$instances = Get-SPAppInstance -Web http://mysite/sites/collection
$instance = $instances | where {$_.Title -eq 'Application.Title'}
Uninstall-SPAppInstance -Identity $instance
Executing this PS command throws...
The System Account cannot perform this action.
There is no option from the Sharepoint UI to remove the application, and retrying the install also fails. I've tried other user accounts to execute this powershell command (other than the system account), but no dice. I will have to delete the developer site collection if there is no other solution.
I'm faced this problem before on my Office 365 SharePoint Online when deploy SharePoint Hosted App. Then I submit Microsoft Service request and work with MS Technical Support Team on this issue. This problem seem to be something error in SharePoint backend database by itself (I'm not sure to consider it is SharePoint defect).
Did you check the app details installation error report? If you get the message:
"The content database on the server is temporarily unavailable."
Need help: Error 'Install App for SharePoint': An instance of this App already exists at the specified location., I'm quite not understand the answer but there is one comment from Jeremy Thake which seem to be deleted on this thread, he said that:
"…so I actually just restarted the whole environment and when Windows
came back up and I went to the SharePoint Site…the App was gone ;-)"
So here is my advice before you commit to delete your site collection:
Try to deploy your to the another developer site collection and check whether this problem still occur as the same.
Try to increase your app version or change app name/title/id and deploy to the same site collection and check whether this problem still occur as the same to your new app instance.
For SharePoint Server, try to restart IIS/Window Server if you're able to do that. Also install any latest SharePoint Update/CU.
For Office365 - SharePoint and have you have license account, you should submit the service request, if not you should wait about several day and try to remove this app instance again through UI.
Hope you can remove your app and know the root cause exactly.
I have faced this issue some times in on-premises SharePoint.
But for solving this I gave another account (or you can use 1 that you have) shell admin rights.
Note this account CAN'T be marked as a System account on SharePoint!!
Then with this different shell admin account you execute the same script. That always worked for me (I also got some strange installation behavior and needed do remove the app).
I've got a classlibrary which defines a couple of helper classes/methods which are used from a classic asp web application. So far, everything works fine. Now I've added a new helper method which signs a PDF file using a third party tool. Using a console application to call this wrapper method, everything works fine. Once I use an asp page to call the exact same method, the call to
X509Certificate2 cert = new X509Certificate2(sigFilePath, sigPassword);
fails with the error "The system cannot find the specified file" (translated from german).
Since the same code works fine called from the console application, i guess the problem must be located somewhere different. Could it be a security issue?
When I wonder if I'm facing a security issue like you do, I just do a quick test : I put the user account the webserver is using in the administrators group, do a quick iisreset, and try again. If it's working know you now it's a security issue. If it's still failing, look somewhere else.
Never forget to then remove the user accoung from the administrators group, and only do that on you own dev machine, not on production servers !!
If it's a security issue, I would then recommend launching Process Monitor (look for procmon in google). It's a Microsoft download. Look for access denied in the result column. You'll then know what's blocking you ...