Unfortunately it is not possible to update/patch SharePoint without occurring some amount downtime. So the only options available to us are to minimize downtime.

I think of downtime in two ways, 'not available' and 'reduced functionality'. The second obviously is more closely aligned to zero downtime however for a large farm it is difficult logistically to achieve.  Reduced functionality is providing your users with a read only farm during the time in which the patching of the primary farm is occurring. This requires the entire primary farm to be swung to another farm with its content DBs set to read only mode. Once patching on the primary farm is complete traffic is redirected back to the primary farm.

Since we want to always keep our downtime window as small as possible we should always follow a good and well tested practice of upgrading a farm to ensure there are no surprises along the way that will impact our downtime. There are two phases of upgrade, laying down updated binaries and running psconfig. The second phase, running psconfig, is the one that is going to take the majority of the time and the time taken is directly proportional to the amount of site collections within the farm. Psconfig upgrades each content DB schema and in many installations this can take many hours to complete. We have found in our testing in many real world deployments that detaching all content DBs other than the CA content DB, running psconfig, and then attaching content DBs back can help reduce the amount of downtime needed when patching SharePoint. One myth that needs to be dispelled now; the reduction in downtime is not achieved because psconfig runs faster or gets better throughput when upgrading the Content DB.

As with most things in SharePoint there are rules around the DB Attach process:
1. Only one Content DB can be attached to a farm at any one time.
2. Once a Content DB has been attached to a farm all of its content is marked as updated and therefore will incur what is effectively a full crawl the first time search crawls this DB. More on this later.

 So taking into account rule #1 there are two ways we can optimize this process to reduce downtime, 1) Prioritize, attach content DBs that belong to Web Applications that are highly sensitive to downtime first and make them available,  and 2)Use surrogates, build out additional worker farms which are used as surrogates to host attaching content DBs.   

 The process of using surrogate farms includes building one or more single server, throw away, farms that are running the same patch level you are upgrading your primary farm to. This process has been well documented here. This approach however has downsides such as the need for additional hardware, the additional time and effort to build out these farms, and the need for your SQL server to be able to handle the additional load.  

 Let's take a look at the steps of a typical upgrade with DB prioritization:

0. Announce and coordinate downtime with IT, users, etc.
1. Take farm offline, typically you are pulling the WFEs out of a load balancer or for the case of reduced functionality, swinging DNS settings to another read only farm replica.
2. Detach all content DBs from the farm.
3. Run WSS and if applicable MOSS upgrade patches on each server and choosing  to not run psconfig. You are only going to run psconfig once, not once for each upgrade package.
4. After all servers have been patched run psconfig on the CA machine. The execution of psconfig will not take near as long because all the content DBs are detached.
5. For each additional machine in the farm and one at a time run psconfig.
6. At this point your farm, without any content DBs, is upgraded and only the content DBs require upgrade.
7. Starting with the web application that is most critical to get back into production start attaching its content DB(s). Once complete put this Web Application back in the load balancer and notify everyone it is back online.
8.Continue running through each additional Content DB until each is attached back into the farm.

I have a tool that I will be releasing soon named CDBManager that will help with the DB prioritization method of upgrade, specifically it allows you to:

• Mass DB detach all the content DBs in a farm
• Reorder content DBs by priority
• Automate the attaching of content DBs and provides ETA of when each DB will be complete (important because there is not a progress indicator otherwise)
• Manages the upgrade.log file by creating an upgrade.log file for each content DB attached. As you may know each time a Content DB is attached to a farm and upgraded a new upgrade log is either created or if one already exists it is appended too. The problem with this approach is that all your upgrade logging is in a single file and not split out by Content DB. CDBManager renames the upgrade.log file after each Content DB has completed attaching with the name of the Content DB. This makes it much easier to go back through each log and analyze what might have gone wrong within a certain Content DB on upgrade.

I have a couple of large enterprise customers that are testing the tool now. Once we get past any breaking issues I publish the bits.

One additional point about the prioritization upgrade approach; should a content DB fail to attach along the way for whatever reason you should continue to DB Attach the remaining content DBs. While the upgrade is progressing along you now have the opportunity to investigate and mitigate the issues with the failed content DB in parallel to the upgrade and once ready retry the DB attach operation.

 So time to revisit DB Attach rule #2. When a content DB is attached into a farm its ID is changed. This has the side effect of effectively marking each object within the content DB as changed. This means that when the crawler service hits this content DB, weather doing an incremental or a full crawl, it will effectively do a full crawl as it believes all the content has changed. The Infrastructure Update (IU) changes all of this and effectively takes this rule out of play. After installing the IU the Content DB is not longer changed. This means an incremental crawl after re-attaching a Content DB is really an incremental crawl. No more full crawls after detaching and attaching content DBs, yea!

The Infrastructure Update (IU) KB article also has this blurb:

 Improvements to the time that is required to update and upgrade Windows SharePoint Services sites.

So what does this mean? Any fix before the IU psconfig updates each site collection in the farm by updating its build version to reflect the most recent value. After installing the IU we only hit site collections to update them if a schema object of the site collection needs to be updated, such as an update to the template schema. This type of update is far less frequently since hotfixes rarely do site collection schema updates (IU however does to support the new search features). The end result is that if a fix does not require a schema update psconfig does not go through each site collection and update the build number, so this will drastically reduce the amount of time necessary to perform the upgrade.

So there you have it, while we cannot upgrade a live farm we do have processes and available fixes that will move us closer to the nirvana of a zero downtime upgrade.

Happy upgrading!

I am a big fan of anything that gives me more insight as to what is happening on my system. One such IIS 6 tweak which I find is greatly overlooked is the additional AppPool logging you can get out of IIS 6. It blows me away that this was not "on" by default -- but that is another blog entry.

The tweek involves modifying the metabase per http://support.microsoft.com/kb/332088 to turn on this additional logging at the AppPool. This KB has a command:

This turns the logging on for the DefaultAppPool however a more global approach, and one that would be useful esp. when you have more than one AppPool like us SharePoint guys is:

It goes without saying but after you set this you want to do some kind of monitoring for these events to get a since as to what is going on with your AppPools throughout the day.

• ULS Logs
• Netmon
• ADO.Net Tracing
• Netstat
• DbgView
• TDIMon
• NT Event Log
• WinDBG (Debugger)
• LogParser
• netdiag

Setup.cmd

Setup_trace.reg

ADO_NET.mof

_startTrace.cmd

Ctrl.guid.todd

_stopTrace.cmd

1. We Installed Netdiag.exe from the Windows Server 2003 CD by running Suptools.msi from the Support\Tools folder.
2. Opened a command prompt and changed directories to %ProgramFiles%\Support Tools. (Assumes you chose the default install path).
3. Ran the following command to verify that there is not an existing IPSec policy assigned to the computer: netdiag /test:ipsec.

I am frequently asked about the various .Net framework versions floating around. As the .Net framework continues to go through its various revs the waters will only become muddier. Here is a quick overview of each version we have to date…

.Net 1.0 – This was the initial release of the framework which as of today only .Net 1.0 SP3 is currently supported by PSS. This only shipped as x86.

.Net 1.1 – This is a side-by-side release of the framework in which no dependencies on 1.0 exist. Hotfixes and Service packs for this version do not affect other framework versions. This only shipped as x86 and the latest Service Pack is SP1. This version also shipped inside the OS on Windows 2003 RTM but only in the x86 SKU. For x64 and IA64 versions of Windows 2003 there is no .Net framework installed by default. The x86 SP1 for Windows 2003 updates the 1.1 framework however it is SP1+ in that it does not have the same binaries as let's say a Windows 2000 machine with .Net 1.1 SP1 installed.

.Net 2.0 – This is a side-by-side release just as .Net 1.1. This version ships as x86, x64, and IA64. Windows 2003 R2 ships this version but does not install it by default. Using add/remove programs on any SKU will allow for installation. There currently is no service pack for this version. The x86 and x64 redist packages can each be installed side-by-side on a single x64 system.

.Net 3.0 – This is the first add-on framework. It adds functionality in the form of WPF, WCF, and WF, plus upgrades the 2.0 binaries by adding a few necessary fixes to make the new components function properly. This version shipped with all SKUs of Vista and has a redistributable package as well. The 3.0 redist package will install the 2.0 framework should it not be present or will upgrade an existing 2.0 installation. The x86 and x64 redist packages can each be installed side-by-side on a single x64 system. Currently there is no Service pack available.

.Net 3.5 – This is another side-by-side for 2.0 and 3.0 which adds functionality and updates the binaries of the previous two frameworks. This version has not been released and not much about it is public at this point but you can assume an x86, x64 and an IA64 version will continue to be available. You can probably also assume this will debut with Windows 2008.

Probably one of the worst KB articles I have seen lately introduces, what has the potential to be a really exciting new feature of WSS 3.0/4.0 – Remote Blob Storage (RBS). This interface allows the storage of "blobs" outside of SQL server in a kind of BlobBank (I call dibs on this name. J). Blobs are the stream of content, a byte[] for those dev heads, which represent files within SharePoint. They are stored alongside their metadata in SQL. Having the ability to move these blogs to external storage systems is a huge win for some whom have TB of SQL storage and whom want to reduce the dependency on SQL for this type of storage.

Simon Skaria plans on blogging about the interface so I will not go into that here however what I did want to cover were some of the pros and cons or as some would say "considerations" when evaluating the Remote Blob Storage API.

Pros

1. Ability to use storage other than SQL Server for blobs.
2. Ability to leverage a lower TCO storage solution for blobs. This point should be scrutinized for each enviroment especially when you consider some of the Cons pointed out below.

Cons

1. Without ISV involvement there is no mechanism to ensure Backup and Restore is consistent between SQL and external storage solution. Since part of the blob, the ID is still stored in SQL and the blob itself is stored elsewhere these items must remain in a consistent state. So bottom line here is you must be careful when planning your backup and disaster recovery strategies.
2. Lack of documentation.
3. Depending on the external solution chosen it may be slower than SQL which would have obvious impact to the performance.
4. The provider works at the farm level only.
5. Removing the provider once deployed is going to be a huge problem should one need to back out.
6. This is custom code that runs all the time within SharePoint; if there is a performance problem, memory leak, etc it will impact SharePoint stability greatly.
7. The O12 implementation is not fully baked and will very likely change for O14. So the likelihood that an O12 provider will need to be rewritten for O14 is very probable.
8. There is no migration path for the provider in an existing SharePoint deployment. New blobs will be stored with your provider while existing blogs will remain in SQL. You may touch the blogs and cause them to be migrated however that has a whole set of other problems.
9. To date there is very little experience rolling out this API. So the real world knowledge is very tribal deep within MSFT and not likely to make it into the public domain in any quick manner.
10. While the API will be supported however it is highly unlikely the support teams will have training or knowledge about its proper use.
11. It is very unclear what the experience will look like while upgrading an O12 using this solution to O14.

BTW if anyone writes a provider I would love to hear about it!

Thanks
Todd

Up to this point Microsoft has always required customers to make a phone call into Microsoft Product Support to receive a hotfix. Today we have made available a web application that allows customers to fill out a simple web form and receive the hotfix by email.

Here is how it works: The form on the site has field entries for the following information:

Country/Region              (Pulldown menu)

KB article number          (Text entry)

Platform                        (Pulldown menu)

Product Language          (Pulldown menu)

E-mail address              (Text entry)

You enter the data listed above and select the "Submit" button .  You are then taken to a submission confirmation webpage.  This webpage lets you know that you should receive a response from a Microsoft Professional within 8 business hours.  The e-mail response that you receive looks like the automated hotfix e-mail that you may have seen should you have ever used the previous call in method.

Happy Hotfixin'.

Todd 

Recently I have been looking into MOSS related certifications and ran across the MCTS certifications. I have narrowed the huge list of certifications and exams down to just those that are MOSS 2007 and WSS V3 specific and have provided links below.

MCTS Certification

Configuration

Windows SharePoint Services 3.0, Configuration

Exam:    70-631: Configuring Windows SharePoint Services 3.0

Related Course(s) : 5060, 5244, 5245, 5246, 5247, 5248, 5249, 5403, 5942, 5943

E-Learning: Collection 5403: Implementing Microsoft Windows SharePoint Services 3.0

Microsoft Office SharePoint Server 2007, Configuration

Exam:     70-630: TS: Configuring Microsoft Office SharePoint Server 2007

Related Course(s): 5061, 5250, 5251, 5252, 5253, 5254, 5255, 5404

E-Learning: Collection 5404: Implementing Microsoft Office SharePoint Server 2007

Application Development

Microsoft Windows SharePoint Services 3.0, Application Development

Exam:    70-541: TS: Microsoft Windows SharePoint Services 3.0 - Application Development

Related Course(s): 999, 5385, 5386, 5387, 5388, 5389, 5390, 5391, 5392, 5393, 5394, 5395, 5396, 5397, 5398

E-Learning: Collection 5385: Developing Solutions with Microsoft Windows SharePoint Services 3.0 and Visual Studio 2005

Technology Specialist: Microsoft Office SharePoint Server 2007, Application Development

Exam:     70-542: TS: Microsoft Office SharePoint Server 2007, Application Development

Related Course(s): None

E-Learning: None    

Since coming to Developer Support in 2003 I have been working with ASP.NET and IIS. 4 years in any group at Microsoft is a good stint and it was time that I moved on. Because I love working with .Net and web technologies SharePoint seemed like a likely choice. Given SharePoint's huge popularity I felt this provided me with an opportunity to learn a technology that was here to stay and which would only get larger. As a platform there is just a ton that you can do with SharePoint and since it is built on top of ASP.NET I am not totally in the woods when it comes to learning this new product.

So going forward my blogs will be more SharePointy in focus and hopefully (fingers crossed) more frequent and (again fingers crossed) as technically accurate and spelling and grammar error free as possible.

Question:

So what happens when you have an x64 development box running Windows 2003 R2 x64 Enterprise with IIS6 in WOW64mode and you want to install the 32bit version of WSS 3.0?

Answer:

---------------------------

Setup Errors

---------------------------

Setup is unable to proceed due to the following error(s):

- This 32-bit product must be run on a 32-bit Operating System. For 64-bit support, please install the 64-bit version of this product.

- Internet Information Services is running in 32-bit emulation mode.

Correct the issue(s) listed above and re-run setup.

---------------------------

OK

---------------------------

Recently an issue came up where an admin was upgrading their Windows 2003 Server OS from 32bit to 64bit but they wanted to keep their ASP.NET application as is and running under WOW. The issue they hit was with monitoring performance counters. While using perfmon they can see the counter data they could not get these to log to a logfile. The solution here is to change the perfmon service to run under WOW64 (x86) if you want to log counters from a WOW64 process.

The following script sets this all up:

sc \\servername config sysmonlog binPath=%systemroot%\syswow64\smlogsvc.exe

Credit for the solution goes to Chris St.Amand of the Microsoft.com Debugging team.

I just completed building my first MSS07 application and I thought I would jot down my thoughts and findings.

My Application

My application is very simple, I only take one piece of information from the user, query a database via a web service and play back a prompt based upon the results of the query. Simple right? Well one requirement was to support both English and Spanish and not speaking Spanish this made it a little difficult. I decided to go with a Managed workflow application as I am very green to Speech development but very familiar with managed code so it just seemed like a good choice. The application currently does all inbound traffic but I hope to extend it to do outbound too. The entire development process took a couple of months of working only at night.

Lessons learned

1. Speech is hard. I have written many command prompt, windows, controls, services, and web applications in my 10 years at Microsoft but developing a good Speech application was not a trivial task. Part of the problem is captured in my #2 lesson learned but speech in just inherently hard to do correctly. I grew to appreciate just how difficult Speech and IVR development can be and was really glad that the Speech team went with Windows Workflow Foundation (WF) as the primary interface. Developing speech applications with WF really works well; a very nice partnership of technologies. Some of the challenges I had was dealing with multiple languages, switching languages, handling silence, handling barge ins, developing a custom grammar, and handling no recognition. Don't get me wrong MSS helps tremendously here but it cannot do everything.
2. Read the docs. Yea I hear this one all the time too but for Speech Server, esp while in Beta, it pays off. The dividends are the saving of time and frustration. Fortunately for me the Speech Server team is not only passionate about developing a solid Speech product but helping out folks such as myself that tend to get stuck from time to time. Their quick and detailed responses to my questions not only resolved my issues but offered insight into how the product works.
3. The samples are your friend. I typically learn by example and the sample applications that ship with MSS07 Beta are very helpful when you need to solve a particular task such as playing a thinking sound, changing languages, handing silence and non-recognition, etc.
4. A really well thought out and user friendly UI directly impacts your user's experience and. For speech applications prompts and grammars are your UI. Do not underestimate the value of professional voice talent when developing a speech application. My first attempt at prompts was when I sent a friend of mine's girl that works for him to a studio to record the prompts. Yuk, that was a $400 lesson. I then used Digital Base Productions; they were easy to work with and very reasonably priced. It is best to not engage a voice talent producer until you are locked in on your prompts, going back and rerecording prompts costs time and money (yea I did this too). I created a spreadsheet (Excel of course) for my prompts with two columns, one for English and the other for Spanish. I had a friend of mine do the translation to Spanish and found not everything translates very well, for example the # key, 'pound' or 'hash'? I used both. Digital Base was able to record my prompts and deliver them in only a couple of days. Ensure that when you have various language prompts recorded that the voice talent's voices are in sync since they will most likely be recorded by different individuals and one voice is not overpowering and the volumes on the wav files are leveled in sync.
5. Unless you speak the language (and I do not) the telecoms will get really confused when trying to match a solution to what you think your needs are. I went to both AT&T and Verizon asking for a VoIP solution where I would get SIP from them which could then be sent directly to my MSS07 server. I got the feeling this is really new for them and AT&T really had a hard time with the request. Verizon finally got it and then offered a solution that required my purchasing Cisco's Call Manager. This was a deal breaker when I priced out Call Manager, WOW$$. I received some good advice from one of the guys on the Speech Server team, Keep it simple. That being said I went with a standard PRI T1 from AT&T. I found that Verizon and AT&T are really close on price however since I already had AT&T and their long distance ('LD' in telecom speak) costs were a bit less than Verizon. A T1 has 23 channels (phone lines) which is way more than I need.
6. I purchased a Mediant 2000 by Audiocodes with a single T1 card. I live in Dallas and there just happened to be an ISV here locally that sold me the Mediant and 4 hours of setup where the tech guys connected to the box and set it up. We probably only used about 30 min of that time however so if you decide to go with a Mediant you may want to try to set it up yourself. It has a web server interface much like many of the home routers. Of course one change we did have to make that was buried pretty deep in the UI was configuring it to send SIP over TCP as its default is UDP but it worked on the 10th test phone call (see next lesson)!
7. So my Mediant did not work on the first call but I used Netmon3 to sniff and found that it has a really nice SIP parser built right in. My problem of course was that MSS supports SIP over TCP and the Mediant uses UDP. With Netmon it was a breeze to figure this out and get it changed on the Mediant.
8. I used a ton of Debug.WriteLine() statements to learn the flow my speech application took through the various turns and learned when various events where raised. This was critical to learning where to place code within the application.
9. AT&T provided me with 100 phone numbers and to keep things simple I just mapped them all to my application. As you can imagine I get plenty of wrong numbers. The occasional wrong number is not such a bother however I noticed I was getting some calls from the same number. To try to keep my LD costs down and keep from tying up my channels I wrote a small piece of code that took the number that was calling and check it against a denied/black list and drops the call if on the list. I monitor my logs for phone spam and fax machines hitting my application and add their calling numbers to my black list. I wish MSS would provide this as I am sure I am not the first person to have to write a kind of firewall for speech.
10. To decide on how I wanted my application to flow I called a ton of different IVR applications to see how they solved various problems and how they handled someone trying to trip them up. I found some I knew I did not want my application to resemble and others that I really liked. One in particular that I liked was American Airlines.

The hardware

Dell Precision 1850 with x64 Xeon processors and 4 GB of memory. 1Gb teaming NIC, runs Speech server like a champ.

Audiocodes Mediant 2000 with a single T1 card.

I developed my application on a Toshiba laptop which although it has a built in microphone I decided to purchase a Plantronics headphone and microphone since I mainly worked on this at night and I kept waking up my wife "talking to my computer". Money well spent.

Thanks

Todd

I just got involved in a case where a customer of mine was hitting the following exception on .Net Framework 2.0.

Exception information:

    Exception type: InvalidOperationException

    Exception message: Hashtable insert failed. Load factor too high.

The callstack for the faulting thread is:

System.Collections.Hashtable.set_Item()
System.Runtime.Serialization.SerializationEventsCache.GetSerializationEventsForType()
System.Runtime.Serialization.ObjectManager.RaiseOnDeserializingEvent()
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject()
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse()
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped()
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped()
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize()
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize()

<<snip>>

Searching around on the Internet I found others too that were hitting this issue. This appears similar to 831730 which is a 1.1 fix, however that fix was checked into the RTM build of 2.0 so we have another issue here. The good news is we have a fix for this issue however we DO NOT have a KB article for it just yet (I am working to correct that now). We have a race condition that is causing this issue and the fix will correct it. The hotfix package is 927579. Yea this KB article and hotfix package does not look like a fix for the above issue however what we need to understand here is that fixes are checked into our source control in a cumulative manner. So as long as the fix is checked in and you get a binary that was built that includes that source after this check-in date you inherit the fix.

So if you are hitting this issue, which seems to be most prevalent in ASP.Net environments, you should call into Microsoft Support and request the hotfix for 927579.

Recently I was asked how one could share session state between two ASP.NET 2.0 applications. Well I had to be totally honest; I had never even looked into this and really did not know why one would want to do this. Well when I was queried about a solution for this problem a couple times by different folks within a week I decided to take a look at the problem and not worry about why anyone would want to share state cross application. Besides who am I to say what people will use or not use, I thought EBAY was a horrible idea when I first heard about it years ago, I though damn everyone will just take your money and not send you the products....

My first thought was that we should write a custom SQL provider that addresses the problem however writing a custom session state provider is not trivial and I like trivial solutions. Out of the box SQL session state can handle storing session from multiple web applications and it prevents session from being shared. The various session state items are stored in a single table 'ASPStateTempSessions' using a SessionId as a primary key. The SessionId is actually the string representation of the SessionId used to identify the user's session plus the ApplicationId. The ApplicationId is created when the session state provider calls the 'TempGetAppID' stored procedure. This proc either creates the id by hashing the application name or returns the id stored for the name in the ASPStateTempApplications table. For each web application that is using a database for session state you will have a row in ASPStateTempApplications that represents that application.

So to work around this segmentation I modified the TempGetAppID stored procedure to always return the same Application ID (in my case '1') and I use a new application name of 'Global Session State Application'. Now any ASP.NET 2.0 web application that you point to this state database will be able to share session.

After the modification to the stored proc I verified the changes have taken effect by looking at the SessionID column in the ASPStateTempSessions table. I now see values like: '13clw2vlrjio0d45opi0qg4500000001' and 'gz3wc5nqeq2es2ezzxfzpbyb00000001', note the last 8 characters of these strings that is my new global application ID.

Here are the changes that I made to the stored procedure. Note that before you run this on your SQL box you may want to empty your ASPStateTempApplications and ASPStateTempSessions tables for general housecleaning. Also you will want to bounce your ASPNet Applications since they only call TempGetAppId stored procedure when the session state module is loaded.

set ANSI_NULLS ON

set QUOTED_IDENTIFIER OFF

GO

ALTER PROCEDURE [dbo].[TempGetAppID]

@appName tAppName,

@appId int OUTPUT

AS

SET @appName = LOWER('Global Session State Application')

SET @appId = 1

SELECT @appId = AppId

FROM [ASPNET Session State].dbo.ASPStateTempApplications

WHERE AppId = 1

IF @appId IS NULL BEGIN

        INSERT [ASPNET Session State].dbo.ASPStateTempApplications

VALUES

(@appId, @appName)

END

RETURN 0

Note about testing ---I have done minimal testing with this solution so please do you own testing and let me know your results. I look forward to your feedback.

Carlo was kind enough to include me in his recent "tagging" activity.

So here are 5 things you probably don't know about me:

1. I recently graduated from SMU with a masters in software engineering.
2. I own an XBOX but I cannot play it for more than 15 min at a time without getting violently ill.
3. My family Veronica, Garrett & Grace are the most important things in my life.
4. I totally love my job. Yea that is corney but true. When I was in high school and working on my undergarduate I always wanted to find something I could do with my life that was rewarding, paid a good salary and that I could work at for hours, days, and years and never get board. Found IT!
5. I live in really hot Texas. I am totally jazzed though about this summer because we decided to finally build a pool.

Looking around at how I got tagged I find that most of my virtual friends have already been tagged...what a bummer.