I may be SOL on this but I thought I would give throw it out for possible solutions.
I am writing a computer access control service to help me control my kids' computer use. Plan on open sourcing it when I have it working. It is written in VB.Net and needs to work on XP through 7.
I am running into all sorts of security and desktop access issues on Windows 7. The service needs to run as admin to execute the NetSh command to disable the network. But I cannot interact with the desktop from the service so I IPC to a UI to handle other stuff, but I still cannot detect from the service if the desktop is locked. Argghh!
I could get it all working from a hidden windows form app if I could just lick the one piece that needs admin permissions: disabling the network.
It does no good if a kid logs on and denies the popup asking if the program should run as administrator and he says no. Also windows 7 will not start a program set to run as admin using
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Anyone know how to get this working? Or have an outside the box solution?
I wish I could provide some references, but I'm failing at my google-fu right now... but I'm pretty sure UAC doesn't apply to services. If you implement your program as a windows service application instead of a (hidden) windows forms application, and set it up to run for your kids' user accounts and not your own, that should work.
UPDATE
Found this on google, haven't played with it at all. Looks sound though... basically, CreateProcessAsUser to run the forms app from your service app that's running as administrator.
Related
I am building a client-server application, this is all running locally on my computer whilst I am developing the system. However, eventually I would like to deploy the server-side part of the application to a server to run 24/7, enabling client applications to connect and consume the service at will. What I would like to know is, when I come to doing this would I simply just install the server-side application on the server, hit run and that's it? That just seems... well not right (to me), is this the way it is done? or is there a lot more to it? I imagine there is, but I can't seem to find any content on this subject.
FYI - the server is a self hosted WCF application.
You'd want to take your program's executable, support dlls and config files and drop them into a folder. Then create a Windows Service to run the program; if you don't use a Windows Service, the program will only run while you're logged on, which isn't good. As a Windows Service, a reboot of the server will bring the program back online even if you're not logged on.
Here's a knowledge base article from MS on how to make a windows service.
http://support.microsoft.com/kb/251192
If you're program is compiled as a DLL, then create a small .exe program to run it (a wrapper) then deploy the program as described in the article.
Good luck.
I have a VSTO-based PowerPoint add-in that runs fine on Office 2007 and Office 2010. I have users running this add-in every day, day-in, day-out.
I'm now working with a new client that uses Citrix for their desktops. I've never really understood exactly how Citrix works, but it appears that no-one has locally-installed software - they just run everything off the Citrix box. It's a very locked-down environment. They use Office 2010 and what appears to be Vista.
Anyway, my add-in is exhibiting strange behavior in this environment. Simply clicking one of my buttons on the ribbon sometimes gives an error (if the "Show addin user interface errors" setting is ON). The error says "An error occurred when calling the callback "ButtonClick".
Other times, clicking the button appears to have no effect at all (although I suspect that it's actually starting to do something and then crapping out before displaying any messages).
I'm confused, because (a) it works elsewhere, and (b) I catch and report exceptions in all my button-click handlers, so I would expect to see an error reported.
Because the environment is so locked down, and it takes literally weeks to get a new version of my add-in rolled out, I don't know how to diagnose this.
Any ideas?
Have you ever used RDP to remote into another Windows machine? To all intents you can consider Citrix to be a much fancier version of RDP. So you have a bunch of servers where users run their apps and desktops, and they connect remotely to them using HDX instead of RDP.
Your customer could be using XenApp or XenDesktop. In XenApp the users run their sessions on Windows 2008 R2 servers, with multiple users sharing each server. XenDesktop is similar except instead of connecting to a server OS, the user connects to their own dedicated workstation image. At a guess your customer is probably using XenDesktop since you say they are running on "Vista".
Diagnosing your problem is going to be tricky without access to a Citrix environment. For my debugging I'll generally install the remote debugging agent on the Citrix machine and debug remotely from my workstation. Occasionally I'll use Windbg or Visual Studio installed directly on the Citrix machine. If your customer is willing to give you access to their environment you can try this.
Other options include:
Add diagnostic tracing to your product.
Citrix provides some compatibility testing services, see: http://citrix.com/partner-programs/citrix-ready/test.html
As to what might actually be going wrong, Citrix does a range of hooking that can cause unexpected behaviour. For XenApp in particular the multi-monitor hooking is the main cause of things going wrong (I am not sure if this applies to XenDesktop as well). If you do a Google search on "citrix disable hooks" you will find a range of links that describe how to disable hooks using the registry. Disabling the hooks in this way certainly works for XenApp. I am not so familiar with XenDesktop, so I don't know if the same techniques apply. I'd certainly recommend trying disabling hooking for PowerPoint to see if your issues go away.
I have a service account in windows 2008 application server to achieve word to pdf conversion. 3-4 days back everything was working fine and all of a sudden the functionality shut down.
I dig into details. The information I got is as below:
When I log in with that service account and try to achieve that functionality, I'm able to do it.
When I log off with service account and try to achieve that functionality, I'm not able to do it.
Conclusion: Somehow the service account gets inactive.
The problem is very weird and i tried each and every combination of permission in Dcom config. Any help in right direction is highly appreciated. Thank a ton in advance.
You already tried to check the Password Never Expires and User Cannot Change The Password options in Active Directory Users and Computers?
Also, try to re-install the application on the machine. If the application cannot run as Windows Service, use the SRVANY.EXE utility to register you application.
I have a WCF service which is hosted in a WinForms application. This WCF service calls a COM component written in ATL on Visual Studio 6. This works just fine on Windows XP. However the COM component fails on Windows 7 when calling GetFileAttributes. It says the path does not exist even though it does. It is a mapped network drive. The only reason I can think of for this is that The WinForms app which hosts the WCF service has to right clicked and Run As Administrator. I am then assuming the COM component effectively gets the same raised priveleges and therefore the mapped drive which existed under the user logged in to the machine no longer exists as far as the application is concerned.
Is this a valid assumption and if so what are my options for solving this?
On Windows 7 (and equivalents) you loose mapped drives when you run as administrator. That's because you basically switch to another login token, and the network drives are mapped only to the non-admin's.
There are a few ways to overcome this, see discussions here and here.
Also, there's a registry setting (not mentioned on those links) that links the two tokens. See KB article about EnableLinkedConnections, a discussion about using it.
I'm looking for a way to allow potential customers to try my application before they buy it.
The product is a windows forms application that requires an SQL Server database to operate.
Although I have a functional demo that the customer can install on their network, I want to make it easier for them by have them "play" with it at my environment.
I remember Microsoft had (has?) something similar. I was testing Visual Studio a few years ago in a virtual environment where I was connecting to a server at Microsoft.
They setup the environment this way so when a user logs off after using it rollback his actions. Or to explain it better: when a user logins it starts with a new, clean environment.
So any projects I've created testing Visual Studio were lost after I logged off.
Any suggestions?
Thanks.
Some solutions that come to mind:
Provide remote access
You could provide access to a running instance of your application via some sort of remote connection protocol, e.g. via RDP or via VNC.
For example, there is a Java VNC client which can run as a Java applet; you could put that on a webpage and have it connect to a VNC session you host on your servers.
Or use Windows Terminal Server, and allow connection via RDP.
Both solutions of course have the drawback that people need to open the appropriate ports, if they are behind a firewall. There might be ways around that, however (e.g. you can run VNC over HTTP).
VM image
A completely different solution: Provide a ready-to-run VM image (for VMWare, VirtualBox or similar) of your application, including server and everything. You would need a demo version of your app though, plus getting redistribution rights for all the proprietary components (Windows OS, SQL server) might get hairy.
Offer videos
Often people do not really need to actually use the app; they are mainly interested to see how it works. So maybe it is enough to host videos of the app in operation. That allows you to put in some advertising for your features, and lets you show the users what they might miss when testing on their own.