I have a COM outproc server written in ATL that registers itself using
_Module.RegisterClassObjects(CLSCTX_LOCAL_SERVER, REGCLS_SINGLEUSE)
and it results in an HRESULT error code 0x80004015 (which means CO_E_WRONG_SERVER_IDENTITY). What causes this error code, and how can I work around this error?
Do you have any specific DCOM permissions set on the server? Alternatively, check the identity of the caller that causes the server process to be launched against the default DCOM permissions. It might be that the caller is service running under particular account and the process is launched as Interactive User.
Here's an article with more info that can help you figure out the problem.
Related
Today our HTTP server had been updated with KB5001382, KB5001393 and KB5001403.
It's a windows server 2012R2 with IIS8 installed
But after those updates I started getting an error on one of my classic asp pages.
set xml0 = Server.CreateObject("AspXml.AspXml")
set xml = xml0.HttpGet(XML_File)
xml.FirstChild2() (error on this line)
Error message:
Microsoft VBScript runtime error '800a01a8'
Object required: 'xml'
I tested the XML_file and it loads fine local and on te server (browser).
My hosting provider says its something about case sensitivity but I can't imagine what they mean...
Please make sure IIS and permissions to registry/files/folders related to the DLL involved.
Searched the registry for the Object name. In this case "AspXml.AspXml"
For all registry entries, you should take ownership of the parent registry folders, so please give read access to IIS user account.
Make sure the files/folders had read/execute permission for the IIS user account(s).
Registered the DLL at the command line for good measure.
Rebooted because restarting IIS didn't seem to do it.
We have a WCF application on our web server. One of the service methods in this app creates an Excel XLS file with data and places the file in a directory so the user can down load the file later.
Our problem is that when this app attempts to create the Excel object, we get this error: Error in Create Excel Helper Workbook, and Application: Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046}
failed due to the following error: 8000401a The server process could not be started because the configured identity is incorrect. Check the username and password.
This is the line that causes the error:
using EX = Microsoft.Office.Interop.Excel;
EX.Application Application = new EX.Application(); //causes error
I did some research and what I have tried is to go into DCOMCNFG - Computers - My Computer - DCOM Config and Right clicked "Microsoft Excel previewer" - properties - Security, then added several groups and users to have Local Launch, Local Activation, etc....
But this did not help. Some of the articles say to choose "Microsoft Excel Application". However, I only see "Microsoft Excel previewer" in my DCOM Config.
Excel is installed on this server but we still have the above problem.
One strange thing is that if I remote into the server, then have my client(browser) on my PC call the service method to create the XLS, this works without a problem.
What do I have to do to resolve this issue?
You can attempt to make this work by setting the IIS AppPool Identity to a user that has interactive logon rights. The interop assemblies actually work by launching an Excel instance on the server and then communicating with it to perform work.
That being said, having gone down this road before, it is a poor solution. The challenges you'll face are as follows:
Issues with DCOM permissions that are difficult to diagnose and resolve (you're running into this now)
Excel processes get spawned on the server and half the time do not close properly, so your application has to be smart enough to go around killing errant Excel processes, or living with the fact that your application is going to leak memory like crazy
It isn't supported or recommended by Microsoft
Office wasn't designed with server-side security considerations in mind
See the following for additional details:
https://support.microsoft.com/en-us/kb/257757
I'm getting this message (on the log) when trying to start a SSAS Tabular Instance on SQL Server 2012. I already have a Multidimensional instance running so this would be a second one. I also tried with the default instance stopped but got the same error.
Message: The service cannot be started: The following system error
occurred: Insufficient system resources exist to complete the
requested service.
I know the message seems obvious but its a DEV server with a lot of free resources (file size, CPU, RAM..)
Did anyone have this error before?
I know this might seem obvious, but just to verify, did you install at least one instance in the tabular mode? The interface (icons) do not always accurately reflect the mode - in particular the SQL Server Configuration Manager shows the icon for the UDM (OLAP) for any type of SSAS instance.
If you are certain that you did install a SSAS instance of type tabular, then are you able to verify (see) that instance in the SSCM? If so, what is the service state, i.e. is it started?
If not, can you manually start the service there? Does the service account have adequate permissions to run the service?
Give me a bit more information if none of these solutions work.
im working on a Window server 2008, in this server i developed a vb.net 2008 console application that open a excel 2003 file and use its contents to create a xml file, so i have two situations:
1. Differences in execution of the program: if i run the application from the Visual Studio or directly from the executable it open and process the excel without problems but if i configured a task on the windows task scheduler or in the adtempus that execute this program its failed and throws this exception:
Exception from HRESULT: 0x800A03EC- at Microsoft.Office.Interop.Excel.Workbooks.Open(String Filename, Object UpdateLinks, Object ReadOnly, Object Format, Object Password, Object WriteResPassword, Object IgnoreReadOnlyRecommended, Object Origin, Object Delimiter, Object Editable, Object Notify, Object Converter, Object AddToMru, Object Local, Object CorruptLoad)
at .Module1.convertExcelToXmlFile(String excelFile)
i have read alot about this exception, but at the moment im unable to resolved, so I want to know how this program can execute correctly from Visual Studio or directly from the execute but failed when its execute on a task if both situations are in the same server? is there a way to fix this behavior?
2. In the console application when i open the excel file with the open method, the file in excel appears for a few seconds then it closed, is there a way to access the excel file contents but that the file dont show in Ms Excel?
thanks.
You should not be using Office Interop in an unattended process.
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
http://support.microsoft.com/?id=257757
There are a number of products that will manipulate Excel docs and run correctly unattended.
Is the Excel file you're trying to open on the network?
If so, the problem is most likely because your Task Scheduler service and any jobs it runs are (by default) running under the local SYSTEM account, which is prohibited from network access.
If you change the task to run under a different account (say, for example, a domain account that you have given privileges for the remote fileshare). (Note that this change may effect how other scheduled tasks run, so you'll want to be quite sure of the permissions needed.)
Just in case you have not figured it out yet, the most-likely resolution which worked for me can be found at this URL :
https://social.msdn.microsoft.com/Forums/en-US/b81a3c4e-62db-488b-af06-44421818ef91/excel-2007-automation-on-top-of-a-windows-server-2008-x64?forum=innovateonoffice
If your server is a 64-bit one, create a folder named 'Desktop' in the below mentioned path i.e. C:\Windows\SysWOW64\config\systemprofile\Desktop
If your server is a 32-bit one, please make this folder C:\Windows\System32\config\systemprofile\Desktop
We're instantiating a VB6 COM component from classic ASP on a Windows 2000 Server using Server.CreateObject. We get the 'invalid progid' error message.
The DLL is registered. In fact we can run a VBS file that uses WSCRIPT to instantiate and run the component so that shows it is registered.
Why is ASP failing to instantiate it? Is this permissions related? We've tried things like putting the IUSR and IWAM accounts in the Administrators group (just temporarily) and it didn't seem to help. We've granted Everyone access to the folder containing the DLL.
We were able to register the DLL on another server and run the same ASP page there so it does work.
Just one other thing: the server may have been renamed at one time (the IUSR account name differs from the machine name).
Any help appreciated!
-Krip
You haven't said what OSs are involved, for example those supporting UAC. You also haven't said how this library was registered.
It is very likely that you tried to self-register this thing (for example running regsvr32.exe) and the registration ended up in a virtualized location. Thus it will only be seen as "registered" by a process running under the same user context and subject to virtualization (no manifest declaring it Vista aware).
It could also be registered "per user" in the user's HKCU, but this normally doesn't happen without taking special action.
Even a PDW package would get around this, but an Installer MSI would be better. Just copying things around and running regsvr32.exe on them is not proper deployment.
Start Procmon and see what registry key your app is trying to access. Then go to that key and see where it points.
I am thinking that you simply misspelled the name of the ProgID in your ASP.