Is it a log to a file or the system log?
Currently trying to create a Windows 7 image for deployment across some laptops. However I'm got a major snag where domain users face a 5 minute or more delay logging in or out.
Admin users don't get this error. The only thing I can see is that an executable file is run at login and logoff for all users. This .exe creates a log record (I use this on our XP clients) and I can see that non-admin users are not creating the log record.
In the event viewer I see errors like this:
The winlogon notification subscriber <GPClient> took 302 second(s) to handle the notification event
- which explains the 5 minute delays!
Not sure what to do with this one. These users work fine in XP so its not a permissions problem to the script/exe. Yet W7 is now useless to me with this sort of problem. We need to run the script as the data is creates is used a lot. The script itself has been working in XP clients for around 5 years!
Is it a log to a file or the system log?
Basically its a VB.exe that gets the username/PC name etc and writes it to an SQL Database with the time and date etc.
The users that 'hang' on Windows7 are working perfectly in XP - the log records appear and the VB.exe takes around 1 second to complete!
Does it run on win7 normally as a limited user? 5 mins sounds like a network timeout issue, perhaps it doesn't have permissions to access the network at that point
I ran it directly as a limited user and nothing happens. No error, no log entry and nothing appears in the event viewer. It uses SQLOLEDB to connect to the database and this seems to work OK as an admin, but times out as a non-admin.
Putting some debug messages into the program shows that the database connection is timing out, but only if you're running it as a non-admin user.
Bizarre - can't be a provider/connection issue then - but what policy setting would cause this!?
And its not the firewall either, as I get the same results when the firewall is disabled. The program generates the error 'SQL Server not found or access denied' which is a pretty vague error meaning it couldn't connect.
Think I'll have to call it quits on this one. Some bug within Windows 7 does not let a user connect to an SQL database using a standard connection string if its from within a program. If I use a UDL the user can connect fine so its not a connection or provider issue.
Another nail in the coffin for W7 as far as I'm concerned. The list of unworkable problems is too long now!
Last edited by GoldenWonder; 9th June 2010 at 09:41 AM.
To get around the problem - run the logon/logoff exe as a scheduled task -
Below is a command line that I use to create schtasks for WPKG on Windows7 machines - there are options available for on logon - or on user session connection and user session end
schtasks /create /tn wpkg /rl highest /tr "\\SERVER\storage\wpkg-start.bat" /sc onstart /ru domain\user /rp password
The key to getting it to work is the "highest" option - which does the elevation bit..
alternatively create the tak in the GUI - by typing task in the Start-Search dialogue and following the steps..
I hope this helps
The odd thing about this problem though is the user can connect to the database ok (I even installed the SQL Management tools and used a restricted user account to connect) and this application works 100% in XP. What I can't fathom is what has changed in W7 that stops a non admin user connecting to a database through a program like this! Even when I make the restricted account a local administrator of the machine it still doesn't work. Yet they can connect with the UDL so it must be a permissions issue or something to do with W7 and ODBC connections.
I'll have a look at the scheduled tasks - I didn't know there was a 'on logon' option. Cheers for the info
Edit: This is more bizarre! I installed VB6 on the W7 machine and ran the app in debug mode, line by line. It worked fine. Compiled the app and ran that - the error came back straight away! There must be a permission somewhere in W7 that stops an app connecting to a database if you're not an admin.
Found out something else today as well. The app is normally run from a network share (no problems there in the past) If I copy the app locally to C:\Program Files it then works.
Last edited by GoldenWonder; 11th June 2010 at 10:59 AM.
Cracked it. The problem is a bit odd. The application that causes the error is held on a network share (\\server\share$) to which normal users have R/O access to the share and Read\Traverse folder etc permissions. Works fine with XP, but you have to give them Full Control on the Share for it to work under Windows 7 - leaving the NTFS permissions the same. Very odd but at least I've found a workaround - might affect other things in the future as well.
There are currently 1 users browsing this thread. (0 members and 1 guests)