On Windows, to sever all network CIFS/SMB:
net use * /delete
On Linux using bash, the ultra useful repeat history:
history | grep whatever_you_want_to_recall
then bang-number from history, i.e.:
$ history | grep restart 431 /etc/init.d/apache2 restart 483 /etc/init.d/sshd restart 501 history | grep restart $ !431
Simple tricks that somehow I always forget. I don't know how, these should be akin to typing by this point. Maybe by posting them I will remember.
An area where I have had little experience is server monitoring on Windows. I've done a fair amount with Linux but never really had a need to do it on Windows. I did some research and looked into Nagios and some commercial software solutions (all starting at around $20,000 with annual licensing fees) but I knew I wanted something smaller and easier to deal with - we're talking about a pair of servers that'll probably grow to a dozen or so over the next year.
I knew about Windows performance counters and I knew I could log them so I went and had a look to see if anyone had written an Excel spreadsheet to make the pretty pictures everyone enjoys. When I resurfaced I came back with Performance Analysis of Logs (PAL) which is an incredible piece of VBScript that saved me tons of time and/or money (depending entirely on which path a parallel me chose in an alternate reality). Essentially what PAL does is crunch the numbers in your binary or text Performance Monitor logs, processes them with profiles defined in XML files, and produces a great HTML report with graphics, links that has further explanation, and most importantly alerts. PAL includes a GUI tool which you can use to point to a log file, choose a profile, answer some questions (four) about your server hardware, do some additional configuration, and generate a log file.
PAL is only part of the solution. If you're like me, you'll want to retain those log files and reports for performance comparison in the future so you can see if your performance changes have the desired effect. You'll need some place to store the logs (zip archiving them is best) and a sane way to manage the *.htm reports it generates. My suggestion (for the manual approach): use MSIE to save your PAL report in *.mht format. Once saved in HTML Archive Format (*.mht) you can delete the directory and *.htm file PAL creates and you have your report in a single file. If you use Firefox, its okay, install IE Tab and direct all "file:///C:\*" to view in MSIE (you may also find this useful for pointing to your Outlook Web Access URL if your organization uses Exchange). Finally the *.mht files are viewable from within OS X, simply give them a *.eml extension and OS X's Mail.app will display them with no issues. (It should also be noted that Firefox has its own web archive-like format you could use just as well, but in part 2 I'll talk about automating this process and include some source code that does this, and uses CDO to make *.mht files.)
To get started with PAL you'll need a few things: PAL, Microsoft's Log Parser, and Office 2003 (or later) Web Components. Fortunately all of these items are free.
PAL (the betas have been working for me using SQL Server 2005 and IIS profiles, and... NICE 2008 HyperV support in beta 8!)
Microsoft Office 2003 Web Components (later versions should work as well)
So great, enough information to be dangerous now. But what should you record? I record the following performance counters on our servers:
PAL may not analyze every single counter but it does hit all the big ones and pretty much covers anything that may be important to you excluding custom performance counters you implement in your own code (more on that in part 3). There are a number of other performance counters you can track depending on what purpose your server serves. If its an IIS web or application host you can track (and display) IIS performance counters; likewise for SQL Server, Exchange, or a host of other applications. PAL comes with many *.xml profile files that contain information on where and how to display the performance data in the reports it generates.
In terms of overhead I've read a lot of people claim there is little to no overhead, and its a greater risk to just not track performance (and setup alerts). I agree with these statements and I have so far not found performance tracking to adversely impact the performance of our production servers.
What about scheduling PAL to run nightly? While you can use perfmon.msc to configure the performance logs and counters they will track you cannot schedule re-occuring jobs. Fortunately logman, a utility included in Windows, allows you to do just that.
logman update logname -b 07/14/2008 23:00:00 -e 07/15/2008 09:00:00 -r
This command will cause the performance log named "logman" to start recording at 11 PM server time on 7/14 and end recording at 9 AM server time on 7/15. The important switch here, -r, will cause the schedule to be recurring so the following evening at 11 PM on 7/15 it will begin recording anew and end at 9 AM on 7/16.
Our company loves to co-locate services. Source control, production servers, HR, you name it, if we can get it out of the building, we do it. So it comes as no surprise that our document management/repository exists out on the internet hosted by a service provider using Microsoft SharePoint.
A very irksome issue with SharePoint and Vista is that for many people SharePoint shares aren't accessible as mappable network drives or through the common dialog for opening/saving files in Office 2007. People upgrading from Windows XP find they suddenly just cannot access their previously mapped and usable SharePoint shares. This problem occurs when you use Vista and attempt to map to a share across http because Vista, coming configured for a much more stringent security model, doesn't do WebDAV over http, only https. If you are having issues with a Windows 2008 server connecting to a SharePoint (or WebDAV) share over http I would imagine the solution below will work for you as well. (And yes, SharePoint or WebDAV over http is probably a silly idea in the first place... obviously if its within your power to https-ify the share that's likely the best solution - even if its via a self-signed cert). (Update: Windows Server 2003 instructions appear below.)
(I ran across a lot of people having this problem, some solutions to similar problems, but the most informative source was a post I found in Robert McMurray's blog.)
The net use command is optional, you can map using the Windows Map Network Drive functionality or even open the share using the common file dialog in Office.
Note that this solution does not fix the fact that with most shared SharePoint hosting providers you cannot map to the root share (that is, http://yoursharepointprovider.tld); you must choose a share. There are ways around this if you have access to the IIS instance hosting SharePoint but since that wasn't my problem I did not explore them.
And yes, what this means is that if you are automating uploading files to SharePoint you don't have to use the SharePoint web service API or the SharePoint SDK to perform such a simple task - you can just use File.Copy and away you go!
Update:
For Windows 2003 server the DWORD value you must add to the registry under the Parameters key above is UseBasicAuth and set its value to 1 and you'll also want to update the AcceptOfficeAndTahoeServers key from 0 to 1. You cannot just net stop/start webclient; instead you must net stop mrxdav then net start webclient. Finally, and this is important if you are using things such as "%20" to represent spaces in your folder names - don't; instead just use spaces or the equivalent character. I found this out from KB841215.
