Do you know how can I execute a Windows application from SQL server? I have written a Windows application (actually it is a EXE file), when it runs by double clicks, it can call to Skype (I am working on Skype API). But when I try to execute it from inside SQL, it will never call to Skype.
I have used xp_cmdshell SP from SQL. I also tried to use this solution from CodeProject. But both of them did not work for me: http://www.codeproject.com/KB/database/xyprocedure.aspx
Any help is appriciated!
Thanks and regards,
Leo
When you execute an external application through xp_cmdshell it will be run by the SQL Server Service account, on the Services desktop. Skype is probably running under your account on the interactive desktop. It's no way you can succeed with that approach. Services are not meant to directly interact with a client program that way.
Instead you have to create small program that runs on your desktop under your credentials. That program would regularly check some kind of work queue in the database. Each work item should contain the information that the small program needs to be able to interact with Skype.
Related
Can an Oracle APEX application be used to run scripts on the client side local (w7) PC?
I would like to be able to communicate with devices on the local PC, collect data and post it back up to the database. This is for the purpose of test automation which was previously done using MS VBA and MS access.
As with any other sort of web application, not easily. For good reason, web browsers generally do not allow web applications to execute random executables on the client machine. If they did, it would be a huge security hole that would allow an attacker to do whatever they want to your machine just because you visited a malicious web page.
Potentially, you could write (or find) an ActiveX control or a Java applet or some other sort of client-side control that could be given privileges to run scripts on the client machine. But that would probably require a pretty substantial amount of "futzing" with permissions that might make the machine vulnerable to malicious web sites.
Assuming that there are a relatively small number of client machines, you could also potentially install the Oracle Scheduler Agent on each of the machines that you want to execute scripts on and then use the Oracle Scheduler on the database to start jobs on the remote machines. If you did this, you could potentially start jobs on any of the client machines from an APEX interface.
I'm trying to connect to Active Directory to look for a specific user, edit that user's properties and save the changes. Seems like a simple task, but I'm having a hard time putting this thing together.
I've tried using VBscript, and allthough it seems it can be done, I have to add the administrator username and password in clear text. Which is NOT a good idea. The script is also triggered from regular users which have no access to Active Directory. So the initial script needs to fire a second script that is run as domain admin.
Someone gave me a tip though. Create a web page or a windows service that the script can call. And that service or webpage connects to AD and makes the actual changes. I guess a windows service would be the cleanest way of doing this.
But I only have Visual Studio Express and it seems I cannot create a windows service with that. The initial script needs to be vbscript, because it's being run from a software where only vbscript is supported.
So what would be the ideal solution here? Would it be possible for the first vbscript to collect the data it needs, pass those as arguments to a second vbscript that makes the actual changes? A vbscript would be easier to maintain, if I need to update more user properties than those I need right now.
We do use Sharepoint as well. Perhaps I could create a webpart that uses javascript to collect the data passed from the initial vbscript and connect to AD that way? Just brainstorming here to find the most appropriate solution :)
The fact that you need to have the administrator's username and password in the script should point out to you that what you're asking for is security through obscurity. Somewhere in your solution, there will be a username and password hardcoded or a program that will perform these tasks without authorizing the client. These are security holes that I would avoid at all costs.
Having said that, the service is probably the least vulnerable. Even though VS Express doesn't have the template, it's not hard to create a service manually. Use WCF to communicate. Run the service as a managed service account, and give that managed service account only the rights it needs to perform its task.
I need to consume an out-proc COM server from both a worker role and a web role in a Windows Azure application. One step I'm almost sure I'll need to do is to alter the access permissions for the COM server - grant "local launch" and "local activation" permissions for the predefined user under which roles code executes.
So far I found there's DCOMPERM utility in Windows SDK samples which contains code that I guess would do that. So I could write similar code and package it into either a separate executable or into the COM registration code of the COM server and run that code from a role start-up task. That's not trivial, but certainly doable.
I only have one major concern before I start.
Are there any reasons why I can't do that? Maybe using out-proc COM servers is not allowed on Windows Azure or something? Are there any such limitations?
Are there any reasons why I can't do that? Maybe using out-proc COM servers is not allowed on Windows Azure or something? Are there any such limitations?
It's not something I've personally done, but if you can install a COM+ server running in a shell exe, then I think you should be able to do what you want - see this recent blog post http://michaelwasham.com/2011/05/15/deploying-a-com-servicedcomponent-to-windows-azure/
I don't think you will hit limitations - but I think you will hit a fair few problems along the way - good luck.
Sometimes I see that some applications allow themselves to be run as a service on Windows, for example Apache HTTP Server allows that. I always ran it as a regular application and never experienced any problems or limitations.
What are the advantages of this?
Is there anything that applications is allowed to do or have when it's run as a service?
What are the advantages for me as a developer, when I write a service vs. a regular application.
The biggest benefit to running an application as a service is that it will continue running even after the current user logs off (and will start running before a user logs on). Also, services normally run under a local "System" account instead of running under the login of a particular user (although services can, and often are, configured to run under a specific user login, usually dedicated to that purpose).
As a developer, you probably won't notice a lot of difference. Processes running on the desktop are usually easier to debug if something goes wrong. Normally you would set up your application to be able to run in either mode, making it both easy for development and appropriate for deployment.
One thing that comes to my mind is that a service can start before a user logs into the system. I would consider a service to be the ideal way to run a daemon that does not normally have a frontend GUI. It's harder for a user to inadvertently quit, and its out of sight and out of mind.
Services run even when no user is logged on. Applications interact with users.
If you need both, you may need to have two components, one running as a service and one interacting with users.
I have written a Windows service to send mails to users in a Sharepoint list based on some condition.
The development server is a stand-alone Sharepoint installation and the Windows service works fine. But,the Production environment has the application(Sharepoint) and Database(SQL) residing on different servers.
So when the Windows service tries to open the list it says " Cannot open database "WSS_Content80" requested by the login. The login failed."
Pease let me know how to proceed.I am struck with this issue for a long time now..
To solve the Issue quick and Dirty way what you can do is grant permission to the Content Database of your SharePoint application for the User in Which Windows Services Run.
But you want to do it in a neat way I recommend you to write a Timer Job for SharePoint. Here not only does the Permission is taken care automatically but you can also deploy it to multiple Web Application if you want it and manage it easily.
The Best Article on the Subject is here MSDN or AC Article.
Another possible answer is to check which account your service is running as. Running it as a more privileged user like the account that is acting as your app pool would work.
Another possible tact is to look into SPSecurity.RunWithElevatedPrivledges method.