Setting up Motion for Fedora 13

Here's a quick and dirty for getting Motion setup with an old AipTek Pen Cam on Fedora 13.

Don't use the RPM, install from source:

Go here: http://www.lavrsen.dk/foswiki/bin/view/Motion/WebHome and download latest version.

Then:

cd /usr/local


tar -xvzf /path/to/motion-3.2.x.tar.gz


cd motion-3.2.x


sed -ie 's/ret = 2/ret = 0/g' video_common.c


./configure


make


make install


cp /usr/local/etc/motion-dist.conf /usr/local/etc/motion.conf


vi motion.conf

Look for webcam_localhost and change it to: off

save motion.conf

motion -n (to run in non daemon mode to test)

Use your web browser locally first and check http://yourip:8081

You should now see live stream of your video.

kill motion (Ctrl-C)

Run it again in daemon mode and test again.

Error 500 After Migrating From IIS6 to IIS7

I was getting an error 500 after migrating from IIS6 to IIS7 using "msdeploy". I couldn't figure out why for a while. Database was OK, proper app pool for ASP was there, and all was referencing each other OK, or so I thought.

The key was to get a better handle on the error. Testing externally I kept getting the generic 500 error. I tried adjusting how the error is shown under ASP for IIS7, but this didn't work.

I read on Experts Exchange to add IUSR to the security of the site and allow it view, read, and write. This didn't work either and I had to revert back.

After further reading, I saw that if I test from the browser locally on the server hosting the site, I should get a better error. BINGO!

Now I get: http error 500.22 0x80070032

This can be due to attributes in web.config being invalid (apparently security and other things were changed in IIS7, so certain attributes will BREAK when carried over from IIS6 to IIS7). Fret not! You don't have to manually go through and change things to get it to work. You can use an application to do that for you. :)

Here's a link that sums up how to do this nicely: http://www.prolificnotion.co.uk/use-appcmd-to-migrate-web-config-from-iis6-to-iis7/

For those who don't want to click, here it is below:

Run this to get the site identifier from your troubled site:

%systemroot%\system32\inetsrv\APPCMD list sites

This will dump info about your sites, you want to look for whatever is in between quotes (the identifier).

Ex.
SITE "MyMostAwesomeSite" (id:2,bindings:http/*:82,state,Stopped)

So in this case the site identifier is MyMostAwesomeSite.

The next step is to run the command that fixes the attributes in web.config:

%systemroot%\system32\inetsrv\APPCMD migrate config "MyMostAwesomeSite/"

If all goes well, you'll get the following response:

Successfully migrated section "system.web/httpModules"
Successfully migrated section "system.web/httpHandlers"

That's it! Test, and hopefully all is back to normal again.

Changing Drive Letter with MSDeploy

I've been doing a lot of migrations from IIS6 to IIS7 recently. This is a handy way of changing the drive letter when using Microsoft Web Deploy to import a site into IIS, say from drive C:\ to D:\

A Full Command Changing the Source Directory of the Archive "msdeploy-site" From "C:\" to "D:\":

Note: That there are no carriage returns, it's one long string.

C:\Program Files\IIS\Microsoft Web Deploy>msdeploy -verb:sync -source:archivedir=D:\msdeploy-site -dest:metakey=lm/w3svc/1863507787 -replace:objectName="metaProperty",scopeAttributeName="name",scopeAttributeValue="Path",targetAttributeName="value",match="c:",replace="d:"

The "replace" here looks for "c:" and changes it to "d:", which will now put the archive under d: when it was originally on c: on the source server.

Excerpt of the relevant part of the command:
-replace:objectName="metaProperty",scopeAttributeName="name",scopeAttributeValue="Path",targetAttributeName="value",match="c:",replace="d:"

Just change the drive letters of "match" with the original drive from the source server and "replace" with the destination drive on the new server.

Now, let's say you wanted to test this command before you ran it. Well then you do this:

C:\Program Files\IIS\Microsoft Web Deploy>msdeploy -verb:sync -source:archivedir=D:\msdeploy-site -dest:metakey=lm/w3svc/1863507787 -replace:objectName="metaProperty",scopeAttributeName="name",scopeAttributeValue="Path",targetAttributeName="value",match="c:",replace="d:" -verbose -whatif

The "-verbose -whatif" will run the command as a test in verbose mode in the command prompt and let you know if there are any issues it runs into and allow you to confirm that the drive letter destination is correct. You can also output this to a file using " > output.txt"

Let me know how this works out for you.

Determining the version of a Microsoft SQL database

This was driving me nuts for a little bit. Once I found out how easy it is, I was flabbergasted.

In SQL 2000

1. Open up Enterprise Manager
2. Right-click on the database
3. Click on Properties
   
4. Click on Options
5. Look under Compatibility Level
   

In SQL 2005

1. Open up SQL Management Studio
   
2. Right-click on the database
3. Click on Properties
   
4. Click on Options
5. Look under Compatibility Level

Database Compatibility Levels:
SQL Server 2008 (100) - SQL Server 2008
SQL Server 2005 (90) - SQL Server 2005
Database Compatibility Level 80 - SQL Server 2000
Database Compatibility Level 70 - SQL Server 7
Database Compatibility Level 65 - SQL Server 6.5
Database Compatibility Level 60 - SQL Server 6.0

Freezing panes in Excel 2008 for Mac

I recently ran into a weird problem in Excel 2008 on a Mac. I couldn't freeze rows.

To freeze rows in Excel 2008 on a Mac:

1. Put your cursor where you want to freeze your rows or columns in Excel
   
2. Go to View
3. Change it to Normal
4. Go to Windows and select Freeze Panes

"Cannot rename file: Cannot read from the source file or disk."

Do you work in an environment that uses Macs and Windows? Do you have a Windows Server that's being used for file sharing? Are you running into the issue, "Cannot rename file: Cannot read from the source file or disk." or "Cannot delete file: Cannot read from the source file or disk."?

I recently ran into an issue where a user reported that their files were missing from the server. Upon further inspection of the Windows server, I noticed that the files were there, but along with them were a lot of forked files. More information on forked files can be found here:
http://xahlee.org/mswin/mac_windows_file_conv.html

At any rate, I thought it might be a forked file issue, so I removed all unnessary forked files and had the user log out and log back in again. This didn't help. I then checked out the properties of the folder in Windows and noticed that it was reporting 0kb in size. Whoa, wait, I see that these are RAW files and there are about 30 of them all 15MB in size! How can the folder be reporting only 0kb in size? Out of curiosity I tried renaming the folder and noticed a trailing space. Dang! The folder is corrupt because of a trailing space! I tried renaming it, and that confirmed my suspicions, "Cannot rename file: Cannot read from the source file or disk." I was pretty confident this wasn't a HDD issue because there were no errors in the Event Viewer, or RAID software. Microsoft has an article about spaces at the end of the title of files and folders corrupting them, and to call Microsoft Support to correct it:

http://support.microsoft.com/kb/814594

You don't need to do that. You can fix it yourself. Here's how:

In Windows
1. Locate the offending folder
2. Create a new folder
3. Delete all unnecessary forked files if you have any.
4. Move the folders contents to the new folder.
5. Delete the offending folder with the following command:

C:\share\offending-folder\>rd /s "\\?\C:\share\offending-folder "
Note the trailing space above. This will work with other illegal characters for NTFS that corrupt the folder.

You'll be prompted with:

\\?\C:\share\offending-folder , Are you sure
Y/N)?

Press Y

The folder will now be deleted, and access to the files moved to the new folder should be restored.

More information can be found here:
http://blog.dotsmart.net/2008/06/12/solved-cannot-read-from-the-source-file-or-disk/

I've done the following before many years ago, but I would suggest this as a last resort.
1. Get a Live CD, that's running Linux. I think I used STD, or Security Auditor when I last did this.
2. Remove the hard drive from the Windows computer and mount it in Linux with ntfs write capabilities
3. Fix the offending file's name.
4. Put the disk back into Windows computer and boot back into it, and check to ensure the file is renamed correctly and no longer causing issues.

Shrinking the Information Store in Exchange When ESEUTIL Doesn't Do It

I recently ran into a problem where after running ESEUTIL /d, the Information Store was still over the 75GB limit that you can expand to in Exchange 2003 Standard SP2. As a refresher, the total size of the Information Store is the EDB + STM, this is what Exchange looks at when it calculates the size of the Information Store.

I'll list a general outline that most people do to clear up "whitespace" in Exchange.

1. Increase the Information Store limit in Exchange via the registry: http://www.petri.co.il/change_store_size_limits_ex2003_sp2.htm
   
2. Archive and then Delete unneeded mailboxes in Exchange
   
3. Run an offline Defrag: Unmount Information Store and run eseutil /d infostore.edb

At this point, the information store is usually reduced and users and admins are happy. But what if the information store is still too big, or too close to the limit? What if you just want to know the size of "whitespace" on the information store before you do the defrag?


Check to see how much whitespace you have in the information store.

Whitespace is the empty space left over in the information store after data has been removed from it. I like to compare it to someone getting really fat, and then all of a sudden losing a lot of weight. Once this happens, there's a lot of loose skin. The loose skin needs to be tightened up again. Well the "space" between the loose skin is "whitespace", and we need to remove it to make the body tight again. Yes, weird analogy, but it's how I remember it. Let's get to how to check whitespace in Exchange 2003. A good article on whitespace can be found here: http://www.msexchange.org/articles/Exchange-Databases-Disk-Consumption.html

1. Navigate to where you have eseutil installed (if you haven't adjusted the path so you can type it anywhere in DOS)
2. Go into Exchange System Manager ("ESM"), and dismount the target 4store.
3. Run the following command: eseutil /ms infostore.edb > sizecheck.txt
/m = filedump mode
/s = streaming file
> = send the output to
4. Check out the file sizecheck.txt, and look a line that says "Free", note the number, and the last number at the end of the file, but before the line that says "Operation Completed in 'x' seconds", note this number too.
Free: 24093
234234

The first number is the SLV Space Dump for the STM file.
The second number is the Space Dump for the EDB file.

Take the SLV Space Dump File and multiply by 4096 bytes
Take the Space Dump for EDB and multiply by 4096 bytes

ex.
24093 x 4096 bytes = 98684928 bytes = 94.1132812 megabytes of Whitespace
234234 x 4096 bytes = 959422464 bytes = 914.976562 megabytes of Whitespace

914.976562 mb
+ 94.1132812 mb
---------------------------
1009.0898432 mb = 0.9854393 gigabytes ~ 1GB

As you can see, by running this offline defrag check, we would be able to regain about 1GB of space off of our Information Store if we ran a real offline defrag. It's important to note that the commands above do not defrag the Exchange Information Store, it's read-only and only calculating and dumping statistics. But, what happens if we still need more space? One clue to this is by adding up the EDB and STM files and comparing that to the sum of the size of all the mailboxes. If you're lucky, you'll see that the sum of all the mailbox sizes is LESS than the information store size. Hmmm....what's taking up the rest of the space then? The answer is Recoverable Items.

Recoverable Items

Recoverable Items are really deleted-deleted items. You have an email, you delete it, and it goes to the deleted items folder. You empty you're deleted items. You have just deleted-deleted items. But wait...They aren't deleted. Oh, Snap!

In Exchange 2003 Recoverable Items, aka "Deleted Items Recovery" is enabled by default. It's 7 days for deleted email, and 30 days for deleted accounts. If you do the numbers, this can be a whole lot of email that's added up. So, how do you add it all up? You don't have to, Microsoft will do it for you, in the MMC.

1. Go to Performance Monitor
2. Remove all the items there by clicking on "-"
3. Click on the "+" to add an item
4. Find MS Exchange Mail, then choose Total Size of Recoverable Items
5. Click on the paper with the lines on it to give you numbers. This will tell you the size of recoverable items in the information store in kilobytes.

Another old school way, is to open up ESM. Click on Mailboxes. Go to view, and add the "Deleted" tab. You can now see exactly what user tends to have a lot of deleted items, or add all the mailboxes up manually to get the total sum of recoverable items taking up space on the Information Store.


Removing Recoverable Deleted-Deleted Items

Now you know how to find out how much whitespace you have on the Information Store and how much Recoverable Items space is in the Information Store. How do you regain the space on the Recoverable Items? Well, just doing an offline defrag will NOT clear this up. To get this done really soon across the entire information store:
1. Open up ESM
2. Right click on the Mail Store, and go to Properties
3. Find the Limits tab, and click on it
4. Change "Keep deleted items for" and "Keep deleted mailboxes for" to "0" for both. Click Apply.
5. Find the Database tab.
6. In Maintenance Interval area, select "Custom" and change it to the soonest time you'd like.

Summary / Explanation

What will happen now is that the online maintenance will completely wipe all Recoverable Items off the face of the Earth. The place where the Recoverable Items were in the Information Store, now turns into whitespace. You'll know it's done once the online maintenance reports that it's done in Event Viewer. Once done, run an offline defrag to regain space. Hopefully your Information Store is shrank considerably. Don't forget to readjust the Recoverable Items policy back to something helpful (a balance between recovering data, and recovering space). If this happens again, or you see the Information Store growing again, you've outgrown Exchange 2003 Standard and are ready for Exchange 2003 Enterprise or greater. For kicks, while you're running the offline defrag to regain the whitespace from the Recoverable Items, you can refresh ESM while viewing the mailboxes with a viewing column of deleted, and you'll see them shrink before your eyes as you refresh your view.

BTW, if for whatever reason it's not reasonable to do this across all mailboxes, you can adjust the retention policy for individual mailboxes by going in Active Directory Users and Computers ("ADUC") and adjusting the retention policy on a per user/mailbox basis, and then run the online maintenance, rinse, wash, repeat.