When first using the protocoll advisor on my app I get reccomended to use the COM/DCOM protocoll for recoring the LoadRunnser VUser script. I am doing so but when starting to record I get a pop-up mesasage saying:
"Trapping Sub Process"
"You must be administrator to record sub processes, recording only main process"
What does this indicate?
Unless you have access to the full source code of the application you are recording and have access to the developers of the application to help you set the filters for COM/DCOM then you should avoid it as if it was ebola-laced bubonic plague. Never use it on a commercial application, such as a browser, where you have no access to the source code.
Also, your error message notes a potential issue with your rights on your host. The installation requirements note that administrative access is the recommended model for use of the LoadRunner tools. The error message as noted seems to imply that you may not have administrative access to your host.
Related
I am receiving an error which says The requested operation requires elevation when I am trying to create an outlook object either by early binding or late binding method with below statements
Set olApp = New Outlook.Application
or
Set olApp = CreateObject("Outlook.Application")
It only works when I open this Excel file with "Run as Admin" mode and run my macro. Can you help me to resolve this issue? I do not want to run my Excel with "Run as Admin..." mode to execute my code.
I am using MS-Office professional 2013 and I am also part of the administrative group on my machine.
The only reason for this that I can think of, is that you somehow have OUTLOOK.EXE itself configured to run as administrator.
Unless you remove that configuration, the only way to instantiate an Outlook application is through an elevated process, since a non-admin process can't spawn an admin process.
Close all instances of Excel, and possibly reboot your computer.
Or in my case, I was able to use SysInternals Process Explorer to kill all instances of Excel and Access (I use VBA in both, with references between the two).
In Windows 10, I find I cannot do some things in VBA if my Excel or Access are started with normal user rights. I found a search result somewhere (which I now cannot find) that recommended starting them with administrative rights. I did so, and it resolved the error. Since then I created shortcuts to always start them with admin rights.
However, the bookkeeping software we use exports to Excel, and it sometimes creates new instances. So when I look in Process Explorer, I find multiple root-instances of Excel, some with administrator rights and owned by Explorer.exe, and others with user rights and owned by the bookkeeping program or some other Windows automation process.
With Windows Task Manager, it doesn't always show all instances. So without it, if closing Excel doesn't fix the problem, it means there's a hidden instance still running, and the only way to fix it is to reboot (or install Process Explorer and use that).
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
Using classic ASP on Windows 7pro or Windows 8.1pro, I connect to a Microsoft Access 2003 database with the connection string "Provider=Microsoft.Jet.OLEDB.4.0;Persist Security Info=False;Data Source=D:\INetPub\KN2014\Databases".
This works fine until I call for user authentication with the code:
sAccount=Request.ServerVariables("LOGON_USER")'NT challenge
if sAccount="" then
Response.Status="401 Unauthorized"
Response.End
end if
The authentication is forced on a different page. If I do this in the same window and then return to the page which connects to the database a 80004005: Unspecified error occurs. Only resolution is to close the window and reopen it. If I manually open a second window (same sessionID!) I get the same problem in the second window. The first keeps working fine, even after a refresh.
I've tried to open that second window with program code, but then I get the error in the first window also.
Searching this site, I have done the trick granting read access on sysWOW64/inetsrv. Also: If I do a clean install for Windows 7, it works fine for a while than "Something happens" (maybe installing VS of Office) and the old problem occurs again. Tricks like using basic authentication, using Kerberos or changing the order of authentication protocols seem to have no effect.
I'm an "old school" developer. I hope someone can help me by providing the most simple classic ASP code to do authenticate using windows verification and read/write access to a Microsoft access db.
With Access you need to make sure that your database working in multi-user mode (available on 2010 and later) and you need to detect when user leave your page to close connection to Access upon exiting/closing your site/page.
That is a curse of Access since earliest versions of it.
Or make sure that you open database without locks. IN SQL server that could be achived by executing following upon opening your SQl statement:
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
But I am not sure if this even possible in Access, better option just to switch to SQL Express.
I have created a small application that auto elevates as administrator using the command:
requestedExecutionLevel level="highestAvailable" uiAccess="false"
This works fine if I run the application locally on the computer. However, if the computer tries to run my execuatable across the netork, it simply crashes on startup with a message "Do you want to send more information about the problem?" error. If I right click and run as administrator, my application will work and will prompt for admin credentials.
The folder I am running my application from (across the network) has full read/write permissions for 'everyone'.
My question is: Is there something I've missed? Why can I run my application locally and not get prompted but across the network crashes or requires admin?
Can anyone help explain what might be causing this issue?
UPDATE
I have checked my event viewer log and it shows the following:
Application: AutoUpdater.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Net.Sockets.SocketException
Stack:
at System.Net.Sockets.Socket..ctor(System.Net.Sockets.AddressFamily, System.Net.Sockets.SocketType, System.Net.Sockets.ProtocolType)
at System.Net.Sockets.TcpListener..ctor(System.Net.IPAddress, Int32)
at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.SetupChannel()
at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel..ctor(System.Collections.IDictionary, System.Runtime.Remoting.Channels.IServerChannelSinkProvider, System.Runtime.Remoting.Channels.IAuthorizeRemotingConnection)
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.RegisterChannel(ChannelType, Boolean)
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(System.String[])
at AutoUpdater.My.MyApplication.Main(System.String[])
I don't understand why it is making reference to System.Net.Sockets?? But that is what seems to be crashing my app.
Make sure that the other computers attempting to run your application have the correct .Net framework versions installed. If users are able to open the executable, there shouldn't be any other issues with permission.
If you have verified the framework versions, see if there is anything in the error report that might point to a reason for the crash. A lot of times there may be something in there that can point you in the right direction.
.NET applications don't like to run from the intranet by default.
Try this:
Go to Control Panel -> Administrative Tools -> Microsoft .NET Framework 2.0 Configuration
Click Configure Code Access Security Policy link
Click Adjust Zone Security
Set the My Computer and Local Intranet to Full Trust
If this works, then it is a local security issue. If you need it scripted out, you can use the caspol exe that is in the framework. Sample
C:
cd %windir%\Microsoft.NET\Framework\v2.0.50727
CasPol.exe -pp off -m -ag 1. -URL Z:\folder\EXEName.exe FullTrust -n FriendlyNameOfEXE
Using Windows 2003, I'm look for a way to create a "logoff script" that will continue with the current logoff then immediately login another user. So, "UserA" logs off. Script fires to login "UserB".
This is part of an application upgrade for a computer where we have written the 'shell'; similar to a kiosk application. For the upgrade we need to logon as 'Adminstrator' then, when the upgrade has completed, logoff 'Administrator' and logon as 'sample_user'. We would like to accomplish this WITHOUT rebooting.
Note, I do not want a script that will initiate the logoff (i.e. "shutdown"). I'm looking for a script that will run upon the user logging off (set via Group Policies). As above, the script should log a different user on.
Thanks.
Don't think it's possible in the stated way (script at logoff).
You'd have to set the machine to logon automatically as a specified account and then log off (having it log on automatically for you) and then you'd have to disable that feature again afterwards, by placing a temporary logon script... generally sounds messy.
The actual setting can be made using tools like Microsofts Shared Computer Toolkit or similar (not so sure how the "normal" registry auto-login behaves at manual logout but I've had an XP kiosk that would automatically log on instantly, even if you logged out manually - you had to override it using some key like shift+logoff to be able to manually specify the login again, so somehow it can be made).
The "easiest" way might be to replace msgina.dll with someone of your own making...
But why are you doing this? Just use runas and start whatever you need to do as that other user without logging off the console user - it's a multi-user system afterall? The desktop is just fluff ^^
(This will anyhow require that the user credentials are available to your script, which kind of makes it redundant as you compromise the security of that account - defying the purpose of having that second account in the first place, for whatever purpose it exists?)
I would try setting the registry to autologon with the user you want, and then simply logging off the admin user. That should log your kiosk-user right back on.
Not sure how to login another user once the current user logs off (not sure if windows would let you...)
But you can use shutdown to logoff:
shutdown /?
Here's some ideas that probaly fall into the "cheap hack" category:
How about logging in at UserB in the first place, and then using runas /user:userA <cmd> to run the first part of the install process?
If that's unacceptable, I know there's a way to make Windows workstations (those that aren't part of a Domain) automatically log in into a certain user account after a restart. Perhaps if you looked into which Registry changes happen, and duplicated them, a reboot would automatically log in that user. (Of course, as a final stage, after userB logs in, you would have to revert those changes :-)
It also occurs to me to wonder if perhaps there's a way for a service to force an open "login screen" to log in as a certain user. Maybe using some method like the way the Remote Desktop does it remotely... If that's possible, then you could create a service that you install before logoff of userA, that would trigger the login of userB.
You can script it with VNC (there are many free versions, take your pick). Set up a VNC server process on the machine to listen on localhost. When the user logs off, your logoff script will connect to the machine using VNC and send the keystrokes necessary to log on the next user. VNC uses the RFB (remote framebuffer) protocol; there are libraries for most popular languages, so you should be able to get something working quickly. Or there are related tools that might help.
If you were to run something like this as a normal script in a given language, it would most likely not work as when you log out of your account, all processes should be killed along with your running script.
You might be able to create some sort of 'service' that would run on a service account (i.e. always active) that would automatically do this user switching for you.
My bets are on Windows Powershell, although I'm not entirely sure what functionality it has as far as actually creating a service.
A quick search brings up the following (The second link is to a forum but it mentions running Powershell as a service and sending that service a parameter which would be the path to your user switching script)
How to Create a Windows Service using Powershel
Powershell Script as a Windows Service
I don't have a Windows 2003 server or a system with a "Group Policies" setup to test my hunch but you could take a look at SU ("switch user") for Windows. Originally part of the Resource Toolkit this has been extended to a new SUperior SU. Do post the results/script if this works.
You could approach this from the perspective of building a remote control utility (like VNC, etc). The big thing here is that if you want access to the Logon screen (i.e. the CTRL + ALT + DEL / username/password) part, the only kicker is that a Windows Service is the only component that can access this, so you'd have to create one.
The only problem I see with this technique as a whole is that even if you spent a great deal of effort getting it to work (and it would be a pretty big effort), the chances of this working successfully with the whole thing originating from a logoff script (i.e. when stuff is shutting down) are low even due to the number of things that can go wrong when logging back on as Administrator.
Just remember that for anything you need to run as an Administrator, there are easier ways in Windows to make that happen (such as Run As, changing the user permissions on the items that need to update, etc).