So I have a site with two servers having identical problems, a iSCSI volume will not initialize in Window's Disk Management utility (or create a partition in DiskPart).
In the GUI Disk Management, I get the error "Logical Disk Manager: The operation did not complete. Check the System Event Log for more information on the error." In DiskPart, I get the error "The disk management services could not complete the operation." The event log doesn't have an error directly explaining these errors, but sometimes I'll get an Application Error 1004, mentioning vds.exe (Virtual Disk Service) faulted. Google and multiple forum searches don't yield much result.
A little about the setup. I have an IBM DS3300 iSCSI SAN attaching LUNs to two Dell PowerEdge 1950s via a Qlogic QLE4062c cards, using SANSurfer software. (They're not sharing a LUN, each server gets a different one).
So I won't bore you too much, I'll leave out the majority of my troubleshooting and homicidal hatred towards these two systems and just give you the answer (or at least the answer that worked for me).
Turns out that the issue lies in the Virtual Disk Service, which Microsoft has a hotfix for here: Article ID: 948699. Once I installed the fix and rebooted I was able to initialize the disk, format, label, and use.
April 07, 2009
April 02, 2009
A quick tip for those new to iSCSI, the Microsoft iSCSI Initiator, and using the two for file sharing.
Setting up the LUN, mapping it as a disk, and putting your file shares on it is great, but there are a few configuration steps you need to take if you experience your share settings disappear every time you reboot (even thought the files remain).
First, ensure that the Server service is dependent on the Microsoft iSCSI Initiator Service. To do this, go into the Services MMC, open the Server service properties, and check under the Dependencies tab. No Microsoft iSCSI Initiator? Open Regedit (Run - regedit.exe) and navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\lanmanserver. Find the key "DependOnService" and set it's value to MSiSCSI. The Server service is responsible for creating the shares; if this service starts up before the iSCSI LUNs are ready on the server, then the shares will not appear.
Second, make sure you set up the Microsoft iSCSI Initiator to automatically restore the connection and drive letters. Under the Targets tab, when you highlighted the target and clicked "Log On", did you check "Automatically restore this connection when the system boots"? If not, remove the connection and log it back on, this time selecting the correct option.
Third, after the drive has been set up and you assigned it a drive letter, go back into the Microsoft iSCSI Initiator software and click on the Bound Volumes/Devices tab. You'll see some funky volume path that looks like gibberish. Highlight it and click Add. Put in the drive letter you assigned and click Ok. This will cause the iSCSI Initiator service to not completely start until the volume has been mapped to the drive letter. Since the Server service now depends on the iSCSI service starting up, it'll have to wait until the volume is available before it can assign share settings.
May 18, 2008
Sorry I haven't been posting regularly, I've been really really busy at work
lately and the little time I've had off I didn't want to do ANYTHING
sysadmin related. Hopefully things will be a bit slower now and I can post
some of the stuff I've been saving up. On to the topic...
I love terminal servers. Unfortunately they can be a bit fragile at times,
especially under higher loads. One load-inducing problem that can occur is the existence of local printer queues on the server itself. Locally mapping a user's printer to the terminal server may seem like a good idea, but typically it isn't the best way to do things. Local printers cause a lot of I/O traffic on your local disks, the drivers take up memory (some drivers will load a nice hunk of memory for each logged in user), and the spooler service will also take up resources that will affect other users. Throw in memory leaks that some printer drivers may have and you'll end up with a pretty good issue as your users pile into the server.
On my network I ran into this exact issue with one of my oldest stand-alone terminal servers. I'm running Windows Server 2003, older but still decent hardware, and about 50-60 heavy users all getting a full desktop. Since I didn't know the issues with local printers when I first deployed the server, I ended up with over 30 local printers, most of which were mapped to printers over slower WAN links. Users started complaining about the server being slow. Investigating, I found a memory leak in the spooler service (restarting it helps a little), and two printer drivers taking up 5 megs each in every user session. (That's about 500 megs of ram wasted when I've got 50 users on the server). At this point I decided to do something about it.
There are two options at this point. I could either manually move each user to a mapped printer on another server (which involved contacting each user, taking over their session, and migrating them), or I could script the move (and the users won't know the difference). I chose the scripting method, especially since I don't like to track down and interrupt the users when it can be avoided.
First things first, set up each printer queue on a print server. This is necessary in either option. Hopefully you have a standard naming convention, because scripting is a lot easier if you don't have to change the printer names. (I'll show you a way to handle printer renames later in this post, but it gets messy if there's more than just a few exceptions).
Next, write up your script. Here's what I've done:
'Find the default locally mapped printer, move it to a print server mapping.
Dim ws, dflt, nCount, to_server
Dim WshNet, WshShell
Dim objNetwork
Set objNetwork = CreateObject("WScript.Network")
' The server where the new print queues are hosted.
to_server = "\\printserver01"
' Find the default printer from the registry, strip out unneeded text.
Set ws = WScript.CreateObject("WScript.Shell")
dflt = ws.RegRead("HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\Device")
nCount = instr(dflt,",") -1
dflt = left(dflt,nCount)
' Create the printer mapping for the client.
On error Resume Next
objNetwork.AddWindowsPrinterConnection to_server+"\"+dflt
' Set the created printer mapping as the default.
On error Resume Next
objNetwork.SetDefaultPrinter to_server+"\"+dflt
To map to a renamed printer queue, add this to the script, right before the part of the script where the printer mapping occurs. If the printer name matches what you specify, it will rename it to the new, renamed print queue.
' Specific mapping for Joe Blow's printer. Change dflt to the printer you want to match.
if dflt="JoeBlow_HP4000" then
' Change dflt to the renamed print queue.
dflt = "Site2_HP4100-JoeBlow"
to_server = "\\printserver02"
End if
Also, if you have a client that uses more than one printer, use the below script to determine this, map them to all their printers, and then set their default printer. The script will try to compare their mapped printer with any one of the printers they need to activate this section of script. This script does an Exit Function, which assumes that this migration piece is part of a function.
' Specific mappings for store 3's printers. This will see if dflt is the name of either of this store's printers
if dflt="str3_HP4250-1" or dflt="str3_HP4250-2" then
' Map both printer that the store employee's use.
objNetwork.AddWindowsPrinterConnection "\\printserver01\str3_HP4250-1"
objNetwork.AddWindowsPrinterConnection "\\printerserver01\str3_HP4250-2"
' Set the default printer to the default the user previously had.
objNetwork.SetDefaultPrinter to_server+"\"+dflt
Exit Function
End if
Personally, I incorporated this code as part of my login script, which runs each time a user logs in. After a few days, all of my users should have their printers mapped to the print server and I'll delete the local print queues and remove the printer drivers.
March 31, 2008
When looking for server and network device monitoring, there are quite a few options, ranging from very expensive to free. Today I focus on a free solution that I use, The Hobbit Monitor.
Hobbit is a system based on a plug-in for the Big Brother Monitoring software. Big Brother has been around for quite some time and was bought by Quest Software a few years ago. Hobbit is very comparable the Big Brother system, keeping most of the same general interface and functionality but adding many new features and overall speed improvements.
Hobbit is a monitoring solution for servers and network devices and allows you to write or use extensions to monitor just about anything that responds over a network connection. A central server controls and collects the monitoring and displays the results via a fairly easy to use web interface. It will track history and trends (via rrd) and provides a built-in reporting tool. If there is an issue (that you've defined), such as a down host, the interface will turn red and will performs any alerting actions that you've defined, such as sending an email or sms message.
A member of the Hobbit team provides a live demo here: http://www.hswn.dk/hobbit/
The alerting function has some great features and is very customizable, but is less than straight forward in its setup. An example the configuration file:
$PHONE=MAIL mycell@acme.com SERVICE=conn REPEAT=2h FORMAT=sms DURATION>10m
$SYSADMIN=MAIL admin@acme.com REPEAT=2h DURATION>10m TIME=*:0600:2300
PAGE=servers/siteone TIME=*:0700:2100
MAIL a_sysadmin@acme.com SERVICE=conn REPEAT=50h FORMAT=plain
HOST=%^win.*
$PHONE
$SYSADMIN
Breaking it down a bit, the configuration is in two parts, the definition and rules of the targets and definitions of the monitoring rules.
The $PHONE definition will email mycell@acme.com only if the conn test (ping test) fails, will repeat the alert every two hours, send the alert in sms format. It will also only trigger if the system has been in alert status for more than ten minutes. The $SYSADMIN definition will email admin@acme.com every two hours on ANY failed test lasting over ten minutes and only between the hours of 6am and 11pm. Those two lines define the targets (whom to email) and the conditions at which to email those addresses.
The PAGE=servers/siteone definition will monitor all the hosts on a page on the server. If your server is http://hobbit.acme.com, then it will monitor all the hosts on http://hobbit.acme.com/servers/siteone. Continuing on that line, the section TIME=*:0700:2100 will only trigger the alert if a host is in alert status between the hours of 7am and 9pm. The next line specifies a target, in this case an email address with some extra rules. The HOST=%^win.* will monitor any hosts that has win. in the name. For example, if you name several servers inside Hobbit win.server, like win.mailserver, win.fileserver, win.appserver. No matter where in Hobbit you have these servers, they will be monitored under this rule. The next two lines, $PHONE and $SYSADMIN just call the predefined targets and use the rules defined there.
As you can see, the alerting functionality is very customizable and, even if the setup isn't point and click, not that hard to set up once you have a little understanding about it. Hobbit also features an easy way to pause or stop alerts via it's web interface. You can stop alerts by test type (like ping test, telnet test, etc), set a duration for the stopage (like no alerts for this host for the next two hours, or until the test turns ok), or even schedule a stopage when you are scheduling some downtime for a host.
As I mentioned before, Hobbit can be extended and customized for greater functionality. You can add more tests either by enabling those built in (refernce the help file for details), by writing your own port tests (also in the help), or by adding extensions. See deadcat.net for a lot of extensions and additional tests. Although the majority of these are geared towards Big Brother, with a little bit of code tweaking they can be easily adapted to Hobbit.
Although this system seems to be Linux/Unix oriented at a quick glance, it provides a lot of functionality for Windows systems utiliziing an agent called BBWin. With BBWin, you can monitor resources such as CPU usage, disk usage, memory usage, running processes and services, uptime, and netstat results. You can also add additional extensions (called externals in BBWin) to test for other things. Configuration is done in an XML file on each server and is very customizable.
You can customize the default warn and panic levels for the CPU usage:
Disk monitoring can be configured with a default warning and panic levels:
Or you can specify specific levels per drive based on a percentage or just an amout of space left:
Remote drives and optical drives can be monitored as well:
Services can be monitored wheter they are running or not. You can also automatically restart the service if you so configure it. You can specify any process running on the server just by adding another line with it's service name. Processes are configured similarily:
Example of the Hobbit overview of some Windows servers utilizing BBWin:
Example of the CPU usage monitoring:
Example of the OpenManage extension I use for my Dell servers:
As you can see, Hobbit is a very powerful and customizable alternative to the other server and network monitoring products out there. With a little bit of reading and some work, you can get this system up and monitoring your systems without too much hassle. Hobbit is definately worth a try if you need a solution and don't have the funds to drop for a commercial solution.
March 01, 2008
I was setting up an old server to act as a print server today and decided to share a tip or two.
Move your print spools to another disk.
Since spooling can take up a bit of I/O, moving this to a disk other than on your system disk can help speed things up a bit. This also helped me a few years ago when I had a 12 GB system partition (remember when vendors shipped drives like that) and needed to free up some space.
1. Open the Printers and Faxes applet.
2. Click on File and Server Properties.
3. Click the Advanced tab.
4. Change the directory of the Spool Folder to the other drive.
5. Click apply.
6. Restart the Print Spooler. Open a command line and run net stop spooler && net start spooler.
Install only the DRIVERS, not the software.
I've seen people do this before, especially with HP or Dell (Lexmark) printers. When setting up a printer on a server, don't run the printer's "install" utility, don't install their special "printer monitor", and don't run any "driver install packages". Always install only the drivers. This avoids all the unnecessary services and processes running on your server. I've found that most of these programs are bulky, eat memory, and will slow down your printing. I've seen a few from the vendors I mentioned already that have memory leaks.
Beware printers on a terminal server.
Actually, don't beware of them. Just don't put them on the terminal server in the first place. Set up all your printer queues on a different server. There are several reasons for this.
1. Disk I/O is an important resource in Terminal Server. When you have 60+ users hammering the same disk at the same time, you don't need 20 print jobs trying to do the same. If you HAVE to have printer queues on the Terminal Server, follow my first tip and move the spools to another disk.
2. Memory usage is another important resource. The print queues will take up memory, but some drivers will spawn a process for each and every user on the system. This adds up quick if you have two or three of these processes per user and a large number of users.
3. If you have a limited amount of hard drive space, periods where there is a high volume of printing will make things much worse (unless you move the spools to another drive).
4. All of your users will see all of the print queues on the system. This can provide some amount of confusion for your users, and you might find them printing to the wrong printer or changing printer settings.
Printer pools and other tips
I found the article Configure IT Quick: Configure print queue servers for efficient printing informative if it's applicable for your environment.
Also see the article Get IT Done: Boost printer performance by adjusting Windows' spool file settings.
September 07, 2006
What is FreeNAS ?
FreeNAS is a small (less than 32Mo) Operating System based on FreeBSD 6 that provide Free Network-Attached Storage services (CIFS, FTP and NFS).
read more | digg story