I'm trying to create a login on our test server with:
CREATE LOGIN [<DOMAIN>\<LOGIN>] FROM WINDOWS;
GO
As opposed to the live server the test server does not have any active directory. So it fails with:
Windows NT user or group 'DOMAIN\LOGIN' not found. Check the name again.
Worth to be mentioned, that on the test server we use a backup of a database dump from the last release and apply new migrations to this dump. This means, that this error would not occur, if a more recent dump from the live server was used, where the active directory login already exists.
To enable proper testing, we discussed three possible options:
Recreate the active directory on the test server: I would like to avoid this, because nobody really wants to administer an additional active directory clone for testing purposes.
Use a more recent database dump: The problem here is, that the live server is not ours and we only have restricted access to it. It is possible, but still not the optimal solution in regard to practicability. Also, it would mean, that we would play in migrations to the live server before having tested them on the test server.
Alternative SQL syntax: I am aware, that there alternative ways of creating logins, e.g., CREATE LOGIN <login_name> WITH PASSWORD. But I could not think of any way, which allows us to create logins depending on which system we are on.
Option 3 is our strong favorite, but we are missing a piece to the puzzle. Anything we are missing here?
You can create a new user on your local computer.
And then add this new user to the instance.
CREATE LOGIN [<domainName or your hostName>\<login_name>] FROM WINDOWS;
In my WiX projects I have two custom actions, in the same DLL. Both are written in C#.
The first one enumerates which IIS-sites are available on the machine. It runs before the Windows Installer dialogs.
The second one runs after a dialog "select which web-site", i.e. in the Dialog-flow as a result of pressing "Next".
The first one logs nicely to the MSI-logfile.
The second one logs nothing at all.
Why cannot my custom action log during the dialog-part? (The rest of the dialog-part is logging as expected.)
Is there something I can do to enable this logging?
Custom actions can't write to the MSI log when they're invoked using a DoAction control event. It's an MSI limitation.
It's a permissions problem.
IIS web site enumeration requires Administrator privileges, so the first custom action runs in an elevated process. Your second custom action runs in a non-elevated process, so it doesn't have enough permissions to write in your log.
If you create the log in a per-user location, for example the current user desktop, the second action will successfully write in the log.
A solution is to use an elevated process for your second custom action. Another solution is to always create the log in a per-user location.
We're instantiating a VB6 COM component from classic ASP on a Windows 2000 Server using Server.CreateObject. We get the 'invalid progid' error message.
The DLL is registered. In fact we can run a VBS file that uses WSCRIPT to instantiate and run the component so that shows it is registered.
Why is ASP failing to instantiate it? Is this permissions related? We've tried things like putting the IUSR and IWAM accounts in the Administrators group (just temporarily) and it didn't seem to help. We've granted Everyone access to the folder containing the DLL.
We were able to register the DLL on another server and run the same ASP page there so it does work.
Just one other thing: the server may have been renamed at one time (the IUSR account name differs from the machine name).
Any help appreciated!
-Krip
You haven't said what OSs are involved, for example those supporting UAC. You also haven't said how this library was registered.
It is very likely that you tried to self-register this thing (for example running regsvr32.exe) and the registration ended up in a virtualized location. Thus it will only be seen as "registered" by a process running under the same user context and subject to virtualization (no manifest declaring it Vista aware).
It could also be registered "per user" in the user's HKCU, but this normally doesn't happen without taking special action.
Even a PDW package would get around this, but an Installer MSI would be better. Just copying things around and running regsvr32.exe on them is not proper deployment.
Start Procmon and see what registry key your app is trying to access. Then go to that key and see where it points.
I am thinking that you simply misspelled the name of the ProgID in your ASP.
As part of our product's installation process, a database is attached to the server.
We use EXEC sp_attach_db in order to attach it to MSSQL.
The problem occures when we try to attach it with "SQL Authentication" connection string - the database is attached to the server as read-only, thus preventing any write access from being performed
This is driving us nuts... it's working just fine with Windows Authentication, and the only difference is the connection string... I tried googling for it but no mention for such a scenario is found.
Any ideas anyone?
It's important to mention that the MDF/LDF physical files are not set with "ReadOnly" attribute, so this is not the problem.
I'm curious why you can't attach the database with write permissions and then just make the whole thing read only after the install?
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).