Monthly Archives: December 2010

How to edit the hosts file on a Mac

The easiest way to edit a Hosts file on a Mac is to drop to the command line and enter the following command:

sudo nano /private/etc/hosts

First Open Terminal.app which is located under the Applications\Utilities folder in Finder.

Type the command as it appears above, and when prompted re-enter in your password. See Fig. 1 Note: You’ll need to be logged in with an account that has Administrator access.

Fig. 1

Once you’ve opened the hosts file use the arrow keys to start a new line under your loopback adapters. You’ll enter hosts by typing in their IP Addresses, pressing tab, and then typing in their host names. Press enter to go to a new line after every IP address and host name combination. In Fig 2. you’ll see that I’ve added two hosts, host1 and host2.

Fig. 2

When you’re done adding hosts and you’ve double checked the spelling and IP Addresses press Control and O at the same to to write-out, or save, the file. You’ll be prompted for a name and location for the file, keep the defaults and press enter. You’ll also be able to see this at the bottom of Fig. 2.

When you’re done saving the file press Control and X to exit the nano application and return to the terminal.

Now try a ping or some other method to make sure that you’re hosts file is working as expected.

Attached Files:

SonicWall LDAP bind Error – Remote Authentication – Bind to LDAP server failed

We’ve setup one of our client’s Sonicwall TZ series routers to allow LDAP authentication for VPN connections. Occasionally we were getting alerts from the SonicWall with the following content:

Subject: *** Alert from SonicWALL *** [SONICWALL NAME]

12/14/2010 17:05:22.544 - Error - Remote Authentication - Bind to LDAP server failed - - Credentials not valid at LDAP server - 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 775, v1772

This email was generated by: SonicOS Enhanced 5.6.0.3-40o (MAC-ADDRESS-NUMBER)

Of course we’d log in and check it out, we’d hop over to the LDAP section, check to make sure that the user account, password, search context and such were proper, and they were. We’d then run a test bind, and of course it would work fine. It stumped us for a few days but we were eventually able to figure out that the account that the SonicWall was using to bind to the LDAP server was getting locked out due to some other non SonicWall related event, and of course when the account was locked out the SonicWall could not perform an LDAP query, and the users could not VPN in. Once the lockout period expired the SonicWall was again able to perform queries, which explained why when we logged in to test, it was working properly.

The moral of the story? Make sure that the account you are using for LDAP on the SonicWall isn’t used for anything else, so that the chance of someone locking out the service account is low, or you could also remove it’s lockout policy and apply a very strong password.

Getting System State Only Backups from Server 2008 / 2008 R2

If you’re like me you’re pretty crazy about backups. I hate not having backups, it never happens that you have an error or a data loss after a successful backup, it’s always after the backup fails. That’s why I always go the extra step and backup core components with their specific tools and then backup those backups with another 3rd party backup software. In server 2000/2003 I used to use NTBackup to make 2 overlapping system state backups, one for Monday, Wednesday, Friday, and one for Tuesday and Thursday. That way if Active Directory ever crapped out on me I’d have the last two days worth of system state backups, and in the original Microsoft form to boot. (it always easiest to do the restore with Microsoft tools, ever get stuck between two vendors swearing it’s the other guy’s fault? )

Anyway, so when Server 2008 came out I wasn’t happy with the fact that I had to either backup the entire C: volume, or that I had to backup to another volume other than the once i was taking a backup of, or that the command line option wasn’t automated. Sometimes you’ve got servers in a rack that only have 1 volume, and there’s not room for a USB drive, or if you’re like me you’re backing up with a 3rd party tool and you just want to keep the native format backups on the server as a spare copy. I ended up doing a bit of research and this is how you get it done:

First you’ve got to enable the ability to backup to the same volume you’re making a backup of. In Microsoft KB 944530 it gives you instructions on how to create a registry entry that enables the ability to backup to any volume. Here is the Location and Key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup\
Name: AllowSSBToAnyVolume
Data type: DWORD
Value data: 1

Or You can download it here: AllowSSBToAnyVolume

Once that’s been done, reboot and then you’ll be able to run a Windows Backup to any volume. Now the next time I do is create two batch scripts, one for MWF, and one for TTh, but again I’m crazy.

MWF’s Backup Batch Script:
Rmdir c:\systemstatebackups\mwf /s /q
Mkdir c:\systemstatebackups\mwf
Wbadmin start systemstatebackup –quiet –backuptarget:c:
Xcopy /s /e /c /h /y c:\windowsimagebackup\*.* c:\systemstatebackups\mwf\*.*
Rmdir c:\windowsimagebackup /s /q

and TTh’s Backup Batch Script:
Rmdir c:\systemstatebackups\tth /s /q
Mkdir c:\systemstatebackups\tth
Wbadmin start systemstatebackup –quiet –backuptarget:c:
Xcopy /s /e /c /h /y c:\windowsimagebackup\*.* c:\systemstatebackups\tth\*.*
Rmdir c:\windowsimagebackup /s /q

Schedule these to run on their proper days and there you have it, the last two days worth of system state only backups, ready to be picked up by a 3rd party backup software, or to be used to restore system state in the event of Active Directory corruption or deletion. It’s maybe a little bit unnecessary, but I’d rather have them and not need them than need them and have to deal with Symantec backup exec support trying to restore a lost CEO user account at 3 in the morning.

Attached Files:

Windows 7 stays on “Applying Settings” for up to 10 minutes

This is the first in what I anticipate will be a long line of “Making Windows 7 play nice” posts.

One of my clients has a Server 2003 domain, with two server 2003 R2 domain controllers. They just introduced their first Windows 7 computers, 2 Windows 7 Professional 32 bit workstations. Each was fully patched, and all of the drivers were updated prior to joining the domain. In addition certain things were disabled like UAC, power settings on the NIC, and hibernate/suspend, before it was joined to the domain.

Once the machine was joined to the domain we started noticing that when users would log in, it could take up to 10 minutes for Windows 7 to stop displaying the “Applying Settings…” screen and actually display the user’s desktop. Once logged in most things were normal, although there did seem to be a lot of sluggishness when browsing UNC paths.
The first place I looked was in the Application Event log and I found these two logged warnings

I stated doing some research and I came across a variety of things to “try” of which these were:

  • Updating the domain controllers with the Group Policy Preference Extensions KB943729.
  • Moving the new computers into their own OU with NO group policies applied, and block inheritance enabled
  • Disabling IPv6 on the client computers, this improved the time from about 10 minutes to about 3 minutes, but still it was taking too long to log in.

I also created a new user in an OU that does not have any policies applied and verified that this user DOES NOT experience the slow login times.

From here I started applying policies one a time to this new user and logging into the computers, it was at the Desktop and My Document redirection policy that the slowness re-appeared for all users, including the new one that previously wasn’t experiencing the problem.

This was a big finding; something in our document redirection group policy was causing the slowness, 3 minutes with IPv6 disabled and 10 minutes if IPv6 was enabled.
I downloaded the RSAT tools for windows 7, installed them, and installed Group Policy Management console. I also created a Central Store for Group Policy Administrative Templates on the Windows 2003 domain by following the procedure on KB929841.
I then set about re-creating the document redirection policy on one of the windows 7 workstations, and creating a new OU for testing. I created another new test user.I moved the test user into this OU and ran a gpupdate /force.

Even with the new OU, New GPO created on a Windows 7 PC and a brand new test user the problem still persisted.
Eventually I remembered that we experienced a problem very similar to this with this client’s Mac 10.5 clients attempting to attach to windows SMB hosts, and the resolution was to disable the TCP/IP Offload chimney on the server. I disabled the offload chimney on the workstation but there was no improvement.

A co-worker of mine eventually found a command to disable auto tuning, and on a whim we tried this on the workstations by running the following command on in the command prompt logged in as the domain admin:

netsh interface tcp set global autotuninglevel=disabled

Unfortunately there was no improvement, until we rebooted, then just like that the problem was gone, existing users could log in quickly, new users could log in quickly, both the old and the new document redirection group policies had no effect on how quickly users could log in. It was a night and day difference; it went from 3 minutes to log in to about 5 or 10 seconds. And the UNC path browsing was much faster as well.
I did not re-enable IPv6 to test that, because it’s not in use on this client’s network anyway.

Getting the impossible-to-use Microsoft Tools for SharePoint 2010 Farm backup to work

So it’s easy enough to get Share Point Central Administration to backup your farm, but it involves logging in every day to click the backup button, which can get tedious. I wanted a way to automate it but of course nothing was easy, after about two weeks to trying this that and the other thing, I came up with a little cheat sheet. It should be noted that I’m not a Share Point or SQL admin, and in fact I’m pretty new to working with either of them, so if you see something that could be improved on, please let me know.

The first time around in our test environment we didn’t install Share Point properly, and we tried to change the service accounts running Share Point through the Central Administration site. I’m not sure if it was bad luck, or something else, but the whole damn thing came crashing down, so please RTFM when installing new-to-you software. We  ended up going back, doing a little more planning, and performed a fresh install. I’ve decided to include some of those planning notes as pre-reqs before we go into getting the backup to work, as you’ll run into permissions problems if they’re not taken care of.

Pre Requisites Notes

Service Accounts:

svcSQL – This account is used to run all SQL related services, regardless of server.

svcSharePoint – This account is the account specified during SharePoint installation, also known as the “farm account” or “timer account” (don’t ask, I don’t understand either)

svcScheduledTask – This is the account under which the schedule task runs, when configuring the task make sure to use this account.

Installation of Applications

Okay, so when you install SQL make sure to use the svcSQL account to run all of the services.

When you install SharePoint, make sure to use the svcSharePoint account as the Farm account when installing. Also make sure to point all of your SQL needs to the SQL server and not a local database.

Assign the following permissions to the SQL databases for each service account:

User: svcSharepoint
Server Instance: SQL_SERVER\SQL_INSTANCE
Server Instance-Wide Role(s):
--dbcreator
--public
--securityadmin

Database Specific Role(s):
-SharePoint_AdminContent_{GUID}
--db_owner
--Public
--SharePoint_Shell_Access

-WSS_Content_Application_Pools
--db_owner
--Public
--SharePoint_Shell_Access

-SharePoint_Config
--db_owner
--Public
--SharePoint_Shell_Access

-WSS_Content_Application_Pools
--db_owner
--Public
--SharePoint_Shell_Access

-WSS_Content_{GUID}
--db_owner
--public

-WSS_Search_SQL_SERVER
--db_owner
--public

User: svcScheduledTask
Server Instance: SQL_SERVER\SQL_INSTANCE
Server Instance-Wide Role(s):
--Public

Database Specific Role(s):
-ALL Databases
--db_backupoperator
--public
--SharePoint_Shell_Access

Actual Backup Procedure

Now that the software is installed correctly we can take backups, if the software is not installed correctly forget about backups you’ll be lucky that central administration doesn’t implode. This is probably one of the most convoluted backup procedures you’ll ever see. Because of the combination of Batch scripts, and trying to call 1 Power Shell script from another, in combination with the fact that the Task Scheduler has a hell of a time with quotes, you end up with this, which is a scheduled task that runs 3 batch files, two of which contain Power Shell commands.

First, Create a new shared folder on the backup server, in this example we called it “data” give Full Control permissions to each service account (all three)

Then, Create a batch script called “cleanup” and put the following in it (adjust for LOCAL path)

rmdir C:\Data\SharepointBackups /s /q
mkdir c:\data\sharepointbackups

Next, Create a new Power shell script called “FarmBackup” (notepad file saved as .ps1) with the following lines (adjusted for UNC path):

Add-PSSnapin Microsoft.SharePoint.PowerShell
Backup-SPFarm -Directory \\BACKUP_SERVER\Data\sharepointbackups -BackupMethod Full

Next, Create a new batch script called “LaunchPowerShell” and put the following in it: (adjust for LOCAL path)

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -command "& 'C:\Data\FarmBackup.ps1' "

Next, Create a new scheduled task that runs with the following settings on each tab:
General Tab:
-Run Whether use is logged in or not
-Run with highest privileges
Triggers Tab:
-Weekly – setup with proper days and times
Actions Tab:
-Create a new action, Run a Program, and run the Cleanup.bat file
-Create a 2nd action, Run a program, and enter the following command (adjusted for LOCAL path) in the Program/Script field:
D:\data\launchpowershell.bat

Run each of the following first to verify that they work before running a test job:

Cleanup.bat
Launchpowershell.bat
FarmBackup.ps1

Failures on either mean that the job won’t run.

Finally don’t forget to backup the C:\Data\SharepointBackups folder with some backup software.

Mac OS 10.6 Clients unable to resolve DNS on Net Extender SSL VPN

Over the last few days I’ve been running into a problem with Mac OS 10.6 clients and the SonicWall SSL VPN client, NetExtender. The client computers were able to resolve DNS properly prior to installation. The problem didn’t appear until after the software was connected to a endpoint, and then disconnected. Once the connection was ended, boom, no DNS resolution.

I had already updated the endpoint device, a SRA 1200, and the NetExtender was whatever version came with SRA 1200 firmware SonicOS SSL-VPN 4.0.0.3-20sv, which was the most recent firmware available at the time of writing.

I started with a review of the release notes of the SonicWall firmware, which mention a problem with Mac OS prior to version 10.6.5 and NetExtender. I updated one of the client Macs to 10.6.5, but still no luck.

A call to SonicWall ended up with them giving me a new version of the NetExtender software for the Mac, version 5.0.680. I updated the first client and Success! I was able to connect, disconnect, and then continue to resolve DNS.

I thought my problems were over until I re-connected to test that the VPN was still working. Now on version 5.0.680 I was unable to resolve DNS on the other end of the VPN tunnel when connected. I could resolve DNS on my local subnet, and on the internet, but I was unable to resolve anything on the internal DNS servers at the main office that I was connecting to. I verified that I could telnet to port 53 across the tunnel, a NSlookup test proved that I the records I was looking for did exist.

I flushed the dns cache, I verified the /etc/resolv.conf file had the two DNS servers that the NetExtender had placed in there when I connected, and I verified with telnet that a firewall was not blocking DNS to the DNS servers.

I called SonicWall back and after much discussion they recommended that we roll back to version 5.0.679. I downloaded the file, removed the current NetExtender and then attempted to re-install the version 5.0.679. It would not allow me to re-install, stating that a more current version was already installed.

I was able to bypass this error by performing the following:

Drop to Command line and enter the following commands:

sudo rm /private/var/db/receipts/com.sonicwall.NetExtender.bom
sudo rm /private/var/db/receipts/com.sonicwall.NetExtender.plist
sudo rm /etc/ppp/sslvpn.*

I then rebooted the Mac and was able to install NetExtender version 5.0.679. Once installed I tested again. I was able to connect and resolve DNS, good. I was able to disconnect and continue to resolve DNS, even better. And Finally I was able to connect again and continue to resolve DNS still.  Version 5.0.679 on Mac OS 10.6.5 was what ended up working for me.

I’ve attached version 5.0.679 for download if you’re experiencing the same problem. NetExtender.MacOSX.5.0.679

Update 1: Upon further review, it appears that NetExtender version 5.0.679 breaks the bonjour protocol on the Macs that it is installed on. To circumvent this problem we actually went back to version 5.0.680, and statically configured a hosts file for all of the major resources on the other end of the VPN tunnel. Click Here to see how to manually edit a hosts file on a Mac. You can download version 5.0.680 here: NetExtender.MacOSX.5.0.680

Update 2: Thomas (see below) pointed out that it doesn’t matter what’s in the resolv.conf file as Mac OS 10.6 and higher no longer uses this file to determine DNS servers. My writing about about double checking this file will have no impact on this particular problem. The rest of the article will still help you work around the problem though, so good luck!