UAC settings can be enforced via group policy in the following area:

Computer Configuration -> Policuies -> Windows Settings -> Security Settings -> Local Policies -> Security Options.

Below are the settings that simulate the 4 options on the slider bar in the GUI.
This information was submitted by Ronnie Vernon MVP, in this thread.

I am re-posting it here mainly for my own convenience in finding it again later.

Commenters on the thread report that the settings go into effect on the workstation, but do not affect the ability of the user to move the slider bar. It will move, the user will be prompted for a reboot, and the setting will be changed when they finish rebooting. Then it will be reset back to the GPO settings at the next GPO processing interval.

When I attempted to follow these directions, I found that the settings available to me in SBS 2008 were slightly different. I did not have an option for “Behavior of the elevation prompt for administrators in Admin Approval Mode = Prompt for consent for non-Windows binaries”. The closest thing was “Behavior of the elevation prompt for administrators in Admin Approval Mode = Prompt for consent”, which set the slider at Level 4. I looked for administrative templates to update this, and did not find anything. I guess level 4 will have to do for now.

***

Admin Approval Mode for the Built-in Administrator account = Disabled

Allow UIAccess applications to prompt for elevation without using the secure desktop = Disabled

Behavior of the elevation prompt for administrators in Admin Approval Mode = Elevate without prompting

Behavior of the elevation prompt for standard users = Prompt for credentials

Detect application installations and prompt for elevation = Enabled

Only elevate executables that are signed and validated = Disabled

Only elevate UIAccess applications that are installed in secure locations = Enabled

Run all administrators in Admin Approval Mode = Disabled

Switch to the secure desktop when prompting for elevation = Disabled

Virtualize file and registry write failures to per-user locations = Enabled

———————————————

***

Admin Approval Mode for the Built-in Administrator account = Disabled

Allow UIAccess applications to prompt for elevation without using the secure desktop = Disabled

Behavior of the elevation prompt for administrators in Admin Approval Mode = Prompt for consent for non-Windows binaries

Behavior of the elevation prompt for standard users = Prompt for credentials

Detect application installations and prompt for elevation = Enabled

Only elevate executables that are signed and validated = Disabled

Only elevate UIAccess applications that are installed in secure locations = Enabled

Run all administrators in Admin Approval Mode = Enabled

Switch to the secure desktop when prompting for elevation = Disabled

Virtualize file and registry write failures to per-user locations = Enabled

——————————————-

***

Admin Approval Mode for the Built-in Administrator account = Disabled

Allow UIAccess applications to prompt for elevation without using the secure desktop = Disabled

Behavior of the elevation prompt for administrators in Admin Approval Mode = Prompt for consent for non-Windows binaries

Behavior of the elevation prompt for standard users = Prompt for credentials

Detect application installations and prompt for elevation = Enabled

Only elevate executables that are signed and validated = Disabled

Only elevate UIAccess applications that are installed in secure locations = Enabled

Run all administrators in Admin Approval Mode = Enabled

Switch to the secure desktop when prompting for elevation = Enabled

Virtualize file and registry write failures to per-user locations = Enabled

————————————————

***

Admin Approval Mode for the Built-in Administrator account = Disabled

Allow UIAccess applications to prompt for elevation without using the secure desktop = Disabled

Behavior of the elevation prompt for administrators in Admin Approval Mode = Prompt for consent on the secure desktop

Behavior of the elevation prompt for standard users = Prompt for credentials

Detect application installations and prompt for elevation = Enabled

Only elevate executables that are signed and validated = Disabled

Only elevate UIAccess applications that are installed in secure locations = Enabled

Run all administrators in Admin Approval Mode = Enabled

Switch to the secure desktop when prompting for elevation = Enabled

Virtualize file and registry write failures to per-user locations = Enabled

Tags: GPO, Group Policy, UAC, User Account Control

My nVidia driver has an option for “use scaling with fixed-aspect ratio”. The idea is that things can scale my screen, but they have to use a fixed aspect ratio when they do it.

This sounds ideal, but the setting refuses to stick when I set it.

After much fiddling around, I figured out how to make it stick, and I have to wonder whether this is a known and unavoidable issue, and whether it might have been documented if I had read the help files.

Basically, what I have to do is trick the system a little:

1. Set the display to a resolution that is 4:3 – for example 1280×960 or 1024×768, and apply it. Tell Windows to keep the changes.

Note: This looks like complete crap, but it’s only temporary.

2. Set the “use nVidia scaling with fixed-aspect ratio” setting and apply it. Tell Windows to keep the changes.

3. Set the resolution back to the native resolution for the monitor and apply it. Tell Windows to keep the changes.

4. Go back to the scaling screen and look. The setting should still be at “use nVidia scaling with fixed-aspect ratio”.

5. Start up your game. Whatever 4:3 resolution it goes to, it will NOT be skewed by the widescreen monitor.

I am fortunate enough to have a video card that can play UT2004 in high resolution in windows mode, so it wasn’t a big deal for that game – but I also still play Starcraft, which can only use the “main display”, only plays in full screen, and uses 640×480 resolution which is really awful when stretched on a 1920×1080 widescreen monitor.

This makes the game playable again, albeit a little fuzzy.

Tags: 4:3 aspect ratio, nVidia

The following are some tips and tricks I have picked up when troubleshooting access to Quickbooks files on a server – particularly when they are set up for multi-user access, and the Quickbooks Database Server Manager is installed. QDSM is there to act as a proxy server, intercepting file requests for QBW files and ensuring that no conflicts arise when more than one user opens the file at the same time.

The error message that you get when you try to open the Quickbooks file goes like this:
Error -6000, -83: “An error occurred when QuickBooks tried to access the company file”.
Of course, there are many, MANY hits when searching this error, and most of them are unhelpful. The knowledge base article on the Intuit website is also fairly limited.

Here is my experience with that error and the things that cause it:

1. There are multiple instances of the Quickbooks Database Server Manager running.

Check this by opening the Services applet and looking for services called “QuickbooksDB17, QuickbooksDB19, QuickbooksDB20, etc.” You only need ONE of these. If there are more than one, remove all except the newest one. Multiple instances means you can have conflicts, because they are both trying to serve the same files.

3. The .ND file contains outdated or inaccurate information.

When the QDSM finds a QBW file, it creates a small text file with the .ND extension matching the QBW’s filename. This file contains information about the server hosting the file, the IP address, whether it is available for multi-user access, and which database engine is serving the file to the users. When this information becomes stale, the solution is to delete the .ND file, and tell the QDSM to run a Scan of the folder the QBW files are in to recreate the .ND files. Deleting and recreating these is especially recommended if you have just cleaned up multiple instances of the QDSM service.

4. The NTFS permissions are wrong.

Yes, the Intuit article mentions this, but they are talking about the user’s access to the files. That’s important, and you should check it, but it’s not what I am referring to here. What I am talking about is the permissions for the QDSM user account. When you install the QDSM, it creates a user account with the same name as the service it creates. When it scans and finds QBW files in a folder, it assigns itself NTFS permissions to that folder so it can do its job. When you have uninstalled and reinstalled the QDSM a few times, or perhaps done a server migration, this user account can become disassociated with the QDSM service and things don’t work right anymore. Maybe the old server was a DC, and the new one is not. In that case the old account is an Active Directory user account, and the new one is a local account. they have the same name but the passwords are different, so Access is Denied.

The best thing to do when you suspect you might have this problem is:

a. Remove the Quickbooks account from the NTFS folder permissions anywhere that it has put itself.
b. Uninstall the QDSM.
c. Delete the user account from both AD and the local SAM, wherever you find it.
d. Reinstall the QDSM.
e. Scan the folders where the Quickbooks files are, and let the QDSM reassign NTFS permissions.

If you’re seeing the 6000, 83 error, and you go through the above steps, there’s a very good chance one of them will sort it out for you.

Good Luck!

5. One or more of the workstations have the QDSM installed and are hosting multi-user access.

A lot of users don’t understand the components of the multi-user Quickbooks system, and will install all options and turn everything on. Either they assume more is better, or they don’t know which parts to say “No” to, despite Intuit’s best effort to try making this easier to figure out. If a user has hosting turned on, and they open a shared file on a server, there will be a conflict with the QDSM running on the server, and other users may have trouble opening this file. Go into the Quickbooks program on each workstation and check for multi-user hosting. In a network with a central file server, no user should be hosting. In a peer to peer network, it’s best to pick a workstation that will do all of the hosting and turn it off for everyone else.

Updated: 2010-06-30
Today, I discovered a new and wonderfully annoying way QuickBooks Database Server Manager can make your life difficult.

I had just completed a server migration. I moved all of the files from the old to the new server. The very last thing I did was to add the old server’s name as an alias to the new server, to help make the transition seamless.
The transition was incredibly seamless, except for QuickBooks.
The QuickBooks multi-user hosting setup was not working. I spent a significant amount of time messing with it myself, and then we called QuickBooks support. They spent over two hours and three levels of support trying to fix it, but could not find the problem.
About an hour after we threw in the towel with QuickBooks support, I had a brain wave – but the QuickBooks user had gone home and I didn’t have access to her PC, so it had to wait for this morning. I tried out the new idea this morning, and it solved the problem.
Here is the symptom, then the problem, and the solution:

Symptom:
QDSM would create the .ND file, and it would have the correct contents, including a local file path to the QBW file.
The QuickBooks file would open on a workstation, but could not change to Multi-User Mode. it got an “H202″ error, indicating that it could not communicate with the QDSM.

Problem:
When opening the QBW file from the workstation, the .ND file would get changed by the workstation. Its new contents would point to the data file path using a UNC path. The server name listed in the UNC path was the OLD server name, because the network drive was still mapped using the old server’s name. The old server name still works, and resolves to the new server, so you would think this would not be a problem, but it is. Apparently, QDSM pays attention to the server name being used to attempt the connection, rather than the IP address or other connection method.

Solution:
Disconnect the mapped network drive, and reconnect it using the new server name. Apparently this allows the workstation to communicate with the QDSM using the correct host name, and it works as expected.

Tags: Quickbooks

Server Operating Systems:

At this time, I see little reason to upgrade to Windows 2008. For what most servers do, Windows 2003 does the job just fine, and is still being supported (with hot-fixes, but not Service Packs) by Microsoft. The software you run on it likes 2003 just fine. Before long, new hardware will be built with Windows 2008 in mind, and Windows 2003 drivers for your hardware might get harder to find. However, I recommend moving to virtual servers at that time, and it will then not be necessary to have Windows drivers for your new server. The virtualization layer (hypervisor) will handle that, and the “virtual hardware” assigned to your server will work fine with Windows 2003 for many years to come.

Exchange 2007? Let’s just not talk about that right now. This is an OS discussion, and I will just say that I intend to resist that one as long as possible too, until Microsoft remembers that if we wanted to manage everything with command lines and scripts, we’d be using Linux with Sendmail or some open-source, command-line driven equivalent.

Terminal Servers, however, could benefit from a Windows 2008 upgrade. Terminal Services (now called Remote Desktop Services) functions have been greatly improved in 2008, specifically in the area of publishing applications seamlessly without giving the users access to the entire desktop – and in the area of remote printing. Remote printing has been a major thorn in your side, and Windows 2008 can help you with that. I believe the new Terminal Services is web-accessible, making it very easy to set up new workstations to use it.

Here is another, more detailed discussion of those improvements.

Is it worth the cost to upgrade? Your customer will have to decide.
Workstation Operating Systems:

I am happy to say that most of my customers have managed to skip right over Windows Vista.

I have not had much experience yet with Windows 7, but my limited experience suggests that Microsoft learned a lot from their Vista flop, and worked to smooth out the rough edges that made people despise Vista. My limited experience also suggests that Windows 7 is still too new for widespread adoption, with pitfalls lurking due to software applications and drivers not being fully compatible with Windows 7 yet.

That being said, we are entering a more sophisticated age of malware and viruses, and it may be time to leave behind the less intrusive security measures we have been enjoying with Windows XP, which is now allowing more and more PCs to become infected – just as it happened with Windows 2000. It will be a rocky time, when we try to balance having appropriate access to our own computers against making them wide open to attacks. Some software will work OK when installed with an administrative account and then used by someone else. Some will not. We’ll have to work out which software requires which installation method, and perhaps sometimes temporarily give a user administrative access to their machine to get something installed and configured, then take it away to help protect them. We can do this with Windows XP for now, and then later with Windows 7.

For the time being, I will recommend that my customers continue to purchase workstations that come with Windows 7 licenses, but have a downgrade to XP installed on them. This will continue for as long as possible, until we start seeing the rate of virus infection become too high, or other factors necessitate a change. The age-old cycle of viruses and antivirus software one-upping each other continues, and maybe we’ll see a comeback of the antivirus software.

For now, Dell is offering workstations with Windows 7 licenses, with Windows XP installed – but only in the Business section.

So, am I just being resistant to change? There is some of that, but I do not embrace change for its own sake. there has to be some benefit, other than the many hours of billable work I could get from pushing customers into unfamilair operating systems just because Microsoft wants to keep their money machine rolling. Let me just say that I was determined to be open-minded abot Vista. I gave it a solid try. When asked whether I wanted Vista or XP on my company-supplied laptop, I chose Vista. I suffered it for 6 months, before finally deciding that enough was enough. I had passed the learning curve and the pain continued. I went back to XP. So no, it is not just resistance to change. There are good reasons for me to hold back. They are related to deficiencies of the new OSes, financial reasons, and the general difficulty of being among the first to move to new technology.

Unless there are specific, compelling benefits to be gained in each scenario, then you won’t see me jumping first to new versions of the OS. Not me, not this time.

Tags: remote Desktop Services, Terminal Services, Virtualization, Windows 2003, Windows 2008, Windows 7, Windows Vista, Windows XP

Maybe your customer’s ISP blocks PPTP. Maybe your customer’s firewall doesn’t forward PPTP properly. Maybe you would prefer not to install an IPSEC VPN client on your workstations, especially one that requires expensive licensing.

OpenVPN may be a good option for you.

I experimented with this today, using its most basic form. It wasn’t difficult to set up, and does the job well enough. You can run a VPN over a UDP or TCP port, which you can easily forward through most firewalls without having to worry about PPTP/GRE compatibility issues.

I tested it on Windows Server 2003 with an XP client. Both were 32-bit. However, it claims to work on 64-bit Vista, so should work on SBS2008 as well.

1.       Download the software from here (command-line only) or here (GUI version). The first one is entirely command-line. The second one includes an icon in the system tray to control the VPN.

2.       Install the app on both the server and the client computer.

3.       Generate a static key by typing the following at a command prompt: openvpn –genkey –secret “c:\program files\openvpn\config\static.key “

This puts a file called static.key in the config folder. You can, of course, go for a more complicated config with dynamic keys, but for the purposes of my initial test, I went with a static key. Copy this key to the c:\program files\openvpn\config folder on both the client and the server.

4.       Create a text file called vpnserver.ovpn in the c:\program files\openvpn\config folder, and populate it with the following:

dev tun
ifconfig 10.8.0.1 10.8.0.2
secret static.key

In this example, 10.8.0.1 will be the IP address the server will use, and 10.8.0.2 will be the IP address of the client side of the VPN.

5.       Create a text file called vpnclient.ovpn in the c:\program files\openvpn\config folder, and populate it with the following:

Remote 1.2.3.4

dev tun
ifconfig 10.8.0.2 10.8.0.1
secret static.key

In this example, 1.2.3.4 is the external IP address of the NAT device that will forward the traffic to  the OpenVPN server. You can use an FQDN here if you want.

Note that the IP addresses are reversed in the “ifconfig” line.

6.       Configure the NAT device to forward UDP port 1194 (configurable) to the OpenVPN server and make sure the server’s default gateway is set to the inside of the NAT device. (UDP 1194 is the default, but you can use another if you like.)

7.       At a command prompt on the server, execute “openvpn vpnserver.ovpn” or use the GUI icon in the system tray to start the VPN server.

8.       At a command prompt on the client, execute “openvpn vpnclient.ovpn” or use the GUI icon in the system tray to start the VPN client.

The two should now connect to each other.

This is the simplest implementation of this VPN software. It can also open the entire local subnet of the OpenVPN server to the client (I tested this). You can set up dynamic keys, user accounts, etc with the more advanced options.

Links:

The Main How-To.

The Mini-How-To for the basic configuration I described above.

The MS KB Article to enable IP forwarding in order to open up the VPN to allow the client to use the entire subnet. 

Tags: OpenVPN, VPN