If you edit a service in Windows 7 and go to the Log On Tab, there is an option to "Allow service to interact with desktop". I'm trying to ensure that it is set for a certain service using VB.NET. Does anyone know of a way to do this?
Note: Doing this during the install of a program is not an option. It has to be done at run time.
Call ChangeServiceConfig with SERVICE_INTERACTIVE_PROCESS. The benefit of using Windows API is that it should takes care of the notification and consurrency part and invalidate the cache in other programs that uses service controller, and when something goes wrong, you get an error code back. Generally speaking you should not access the registry if you can use API to get/set a setting.
Service configuration is stored in the registry, under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\
With a key for each service.
It appears that the third to last flag within the Type value corresponds to the 'interact with desktop' value.
For example, a service set to NOT interact with the desktop has a value of:
Type REG_DWORD 0x0000010 (16)
whereas that same service, when set to be allowed to interact with the desktop has a value of:
Type REG_DWORD 0x0000110 (272)
I can't say that this is guaranteed as I've not done any testing, but it may be a good place to start. You'd need to restart the service before the changes to this value take effect.
Related
i have defined a dev.properties file for the mule flow.where i am passing the username and password required to run the flow.This password gets updated everymonth.So everymonth i have to deploy the code to the server after changing the password.Is there a way , where we can keep the properties file outside the code in mule server path.and change it when required in order to avoid redeployment.
One more idea is to completely discard any usage of a file to pickup the username and password.
Instead try using a credentials providing service, like a http requestor which is collecting the username and password from an independent API(child API/providing service).
Store it in a cache object-store of your parent API (the calling API). Keep using those values, unless the flow using them fails or if the client needs to expire them after a month. Later simply refresh them.
You can trigger your credentials providing service using a scheduler with a Cron expression having Monthly Triggers.
No, because even if the properties file is outside the application, properties are loaded on application deployment. So you would need to restart the application anyway to pick up the new values.
Instead you can create a custom module that read the properties from somewhere (a file, some service, etc), assign the value to a variable, and use the variable instead at execution time. Note that some configurations may only be set at deployment time, so variables will not be evaluated as such.
If the credentials are not exposing your application security or data, then you can move them to another config file(place it Outside mule app path). Generate a RAML file which will read & reload the credentials after application deploy/start-up, and store them in cache with timeToLive around 12 hours.
The next time when you have to change Username/Password, change in the file directly and cache will refresh it automatically after expiry time.
Actually not because all the properties secure properties needs to be there at runtime and is it is not there your application will get failed,
There is one way but it’s not best one, instead of editing code you can directly edit secure property I.e username and password in your case directly in cloudhub runtime manager properties tab.
After editing just apply changes then api will restart automatically and will deploy successfully
What's the best practice when you have dependencies that you want to be able to configure when creating a PowerShell module in C#?
My specific scenario is that the PowerShell module I am creating via C# code will use a WCF service. Hence, the service's URL must be something that the clients can configure.
Is there a standard approach on this? Or will this be something that must be custom implemented?
A somewhat standard way to do this is to allow a value to be provided as a parameter or default to reading special variable via PSCmdlet's GetVariableValue. This is what the built-in Send-MailMessage cmdlet does. It reads the variable PSEmailServer if no server is provided.
I might not be understanding your question. So I'll posit a few scenarios:
You PS module will always use the same WCF endpoint. In that case you could hardcode the URL in the module
You have a limited number of endpoints to choose from, and there's some algorithm or best practice to associate an endpoint with a particular user, such as the closest geographically, based on the dept or division the user is in, etc.
It's completely up to the end user's preference to choose a URL.
For case #2, I suggest you implement the algorithm/best practice and save the result someplace - as part of the module install.
For case #3, using an environment variable seems reasonable, or a registry setting, or a file in one of the user's profile directories. Probably more important than where you persist the data though, is the interface you give users to change the setting. For example if you used an environment variable, it would be less friendly to tell the user to go to Control Panel, System, Advanced, Environment, User variable, New..., than to provide a simple PS function to change the URL. In fact I'd say providing a cmdlet/function to perform configuration is the closest to a "standard" I can think of.
I tried using MULTI_MODE_PROCESS above API Level 11. But still I am not getting updating values in activity and values were updated in remote service. I am not able to share preferences in remote service and activity even in froyo,ginger bread versions.Is this a bug in Android ? Any solution we have for this ?
Without code, it's not clear exactly what you're doing, but my guess is that you did the same thing I did at first: simply change your existing call to getSharedPreferences() to use MULTI_MODE_PROCESS and expect synchronization. That's not enough; you also must call getSharedPreferences() again (with the multi-process flag) before accessing the SharedPreferences that may have been changed by another process.
Within VB.NET, trying to find an easy way to in a sense check the check-box "Use Windows to configure my Wireless Network Settings". This is an option that forces windows to use your wireless over third-party programs that may try to steal control. I am aware this requires to have WZC enabled within services and that's something that can be easily accomplished one way or another.
I doubt or rather cannot find a proper registry value or API call to check or initiate such a task.
I would use a registry-recorder to record the changes when manually changing the value, then its a piece of cake to implement the register change in code.
There are plenty programs that can be used to see what changes has been done in the registry, here are one free: http://www.kephyr.com/systemsherlocklite/index.phtml, but google may find more or better variants out there.
With this tool, create a registry dump:
systemsherlock.exe -dump d1.dat -regdirs HKEY_ROOT
Do the change in the wireless network settings
Do a new dump of the registry:
systemsherlock.exe -dump d2.dat -regdirs HKEY_ROOT
And last, compare them and see what has changed:
systemsherlock.exe -compare d1.dat d2.dat
I have a Windows service built upon ATL 7's CAtlServiceModuleT class. This service serves up COM objects that are used by various applications on the system, and these other applications naturally start getting errors if the service is stopped while they are still running.
I know that ATL DLLs solve this problem by returning S_OK in DllCanUnloadNow() if CComModule's GetLockCount() returns 0. That is, it checks to make sure no one is currently using any COM objects served up by the DLL. I want equivalent functionality in the service.
Here is what I've done in my override of CAtlServiceModuleT::OnStop():
void CMyServiceModule::OnStop()
{
if( GetLockCount() != 0 ) {
return;
}
BaseClass::OnStop();
}
Now, when the user attempts to Stop the service from the Services panel, they are presented with an error message:
Windows could not stop the XYZ service on Local Computer.
The service did not return an error. This could be an internal Windows error or an internal service error.
If the problem persists, contact your system administrator.
The Stop request is indeed refused, but it appears to put the service in a bad state. A second Stop request results in this error message:
Windows could not stop the XYZ service on Local Computer.
Error 1061: The service cannot accept control messages at this time.
Interestingly, the service does actually stop this time (although I'd rather it not, since there are still outstanding COM references).
I have two questions:
Is it considered bad practice for a service to refuse to stop when asked?
Is there a polite way to signify that the Stop request is being refused; one that doesn't put the Service into a bad state?
You can't do this. Once the SCM sends a SERVICE_CONTROL_STOP to your service, you have to stop.
If your other apps are also services, you can make them dependencies within the SCM. Of course, if the apps using this service are just regular applications that can't be used.
When ATL's lock count increments to 1, call SetServiceStatus() with the SERVICE_ACCEPT_STOP flag omitted in the SERVICE_STATUS::dwControlsAccepted field. Then you will not receive any SERVICE_CONTROL_STOP requests at all. Any attempt to stop the service will fail immediately. When ATL's lock count falls back to 0, call SetServiceStatus() again with the SERVICE_ACCEPT_STOP flag specified.
I just had to do this in 2 (older) ATL-based services, and it works well. Granted, I was unable to figure out the best way to override Lock() and Unlock() directly, so I just put a small loop inside my service that checks GetLockCount() at frequent intervals and calls SetServiceStatus() when needed.
In your constructor, update m_status.dwControlsAccepted removing SERVICE_ACCEPT_STOP. For instance:
CMyServiceModule::CMyServiceModule()
: ATL::CAtlServiceModuleT<CMyServiceModule, IDS_SERVICENAME>()
{
m_status.dw &= ~SERVICE_ACCEPT_STOP
}