Archive for the ‘Not in the Windows Box’ Category

Change the MAC address in an ESXi VM

April 8th, 2010 by Paul Sterley | No Comments | Filed in ESXi, Hardware, Migration, Not in the Windows Box, Virtualization, Windows Server

 

Last year, I messed around with changing the MAC address in an ESXi VM to avoid some problems with a license manager app that binds to the MAC address of the NIC when you install and license it. I was unsuccessful in my attempt to change the MAC address then. The MAC address in the VM Settings window refuses to allow you to set the first six digits, requiring you to keep the vendor code of a VMware NIC.

 

The NIC driver inside Windows, however, has an option to set the MAC address. Go to the NIC adapter properties, Advanced tab, and select NetworkAddress.

 

nicpropertiesmacaddress 

The server now thinks it has the MAC address you specified.

It works for IPCONFIG /ALL, it works for workstations that ping the server and then check their ARP cache, and it works for FlexLM, the aforementioned license manager software.

 

NOTE: I tested this in Windows 2003 SP2 on ESXi 3.5 and 4.0, and Windows 2008 SBS Edition on ESXi 4.0.

 

Further note: If you do this, it is critical that you NEVER light up the network card in your old server, which has the same MAC address, on the same physical segment of your network. It will bring down connectivity to your new server.

It is possible that you can avoid this problem and continue to use your old server in some other capacity if you change its MAC address, or if you install a different NIC. If the NIC with the matching MAC adddress is onboard though, you may still have trouble connecting to your new server from your old one. This bears testing at some future date when I have way too much time on my hands.

Tags: ,

Updated: Quickbooks 6000, 83, H202 Error – Usually the Quickbooks Database Server Manager

December 18th, 2009 by Paul Sterley | 2 Comments | Filed in LOB Software, Not in the Windows Box, Windows Server, Workstation OS

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:

Serve DHCP While Restoring Your Server

July 30th, 2009 by Paul Sterley | No Comments | Filed in Not in the Windows Box, Windows Server

How many times have you found yourself restoring a server which happens to be the DHCP server, and the leases start expiring? Suddenly, it goes from one server being down, to the entire network being down.

I find that when fixing problems with servers during business hours, the users will often be quite content to leave me be, as long as they can surf the web while I work. Sometimes they cannot do this becase the server is also the DNS server.

It’s not worth the time to set up a temporary DHCP server, right?

Wrong.

There is an open source project called Dual DHCP DNS Server. It’s free, it’s powerful, and it is very quick and easy to set up. Assign a static IP address to any workstation, download and install this, adjust a few lines in the INI file, and you’re off and running. the installation takes only a few seconds. At the end, without a reboot, it (optionally) starts the service.

You just need to edit the DualServer.ini file, and edit a few lines. The most important ones for a simple setup are:

[DHCP-RANGE]
DHCP_Range=192.168.2.100-192.168.2.199
Subnet_Mask=255.255.255.0
DNS_Server=4.2.2.2
Router=192.168.2.1
Lease_Time=1000

Override the default settings and adjust them for your network, (re)start the service, and you’re good to go.

Of course there are plenty of options in there, and you can get as complex as you want with this utility – but if you’re like me, you’d rather do that with a fancy GUI DHCP server built into Windows. For a free quick-start simple DHCP server though, this is the ticket.

Tags: ,

OpenVPN: An Alternative to PPTP or IPSEC Clients

May 7th, 2009 by Paul Sterley | No Comments | Filed in Not in the Windows Box, Windows Server, Workstation OS

 

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:

Trend Micro WFBS Update Problem in SBS2008

January 26th, 2009 by Paul Sterley | 2 Comments | Filed in Antivirus Software, Not in the Windows Box, Trend Micro, Windows Server

I dont know yet whether this is a problem that all SBS2008 machines will have with Trend Micro Worry-Free Business Security, or whether it’s just a weird problem that mine had.

I kept getting e-mails from the Trend Micro Security Server with the following message:
Trend Micro Security Server – At least one Exchange server is outdated.

LiveStatus showed At least one Exchange server is outdated.
Expanded the Updates row and clicked the Deploy Now button as directed. No results.

In the Security Settings tab, selected the Exchange agent, and saw that the patterns are out of date.

In Reports -> Log Query, I ran the following report:
Time range: Today
Type: Exchange server
Content: Update logs

I saw this message, repeated: Web server authentication was unsuccessful. An invalid username or password was entered. Please check your settings and make any necessary changes, and then try again.

Tech Support told me to manually copy the updated pattern files (lpt$vpn###) in place, just in case the files were corrupt. This updated them once, but they refused to update automatically afterward.

Tech Support told me to create a new application pool in IIS which uses the LocalSystem built-in account, and switch the SMEX Website to use this new app pool. This was very promising, given the error message in the log, but it didn’t work.

Tech support told me to uninstall and reinstall the messaging security agent.

Tech support told me to reboot the server (the “Hail Mary” approach).

Finally, what solved the problem was an intuitive leap. I figured “Well, I’ve given the website all of the permissions it could want, and I’m still getting a web authentication error. Wait, what’s this other website here called OfficeScan?”

I assigned the custom application pool (the one that uses LocalSystem) to the OfficeScan website, and I have not had a problem updating since.

Tags: ,