MOSS 2007 Never Stops Crawling

I have come across the issue where our MOSS test farm never completed its initial crawl.  Whenever a search was done from a MySite, the dreaded, 'No results matching your search were found.'

The initial internet search I did, brought me in the direction of this wonderfully written troubleshooting blog about indexes and maintenance plans conflicting with each other, and locking up the indexes: http://blogs.vertigo.com/personal/michael/Blog/archive/2007/01/23/sharepoint-2007-search-never-stops-crawling.aspx

Our setup already had been configured correctly with the duplicate index allowance.  The solution we had was much more in front of us.

After battling through getting access to the shared services administration - I noted that the number of items crawled was at zero.  Since our setup was still pretty much virgin, with two site collections and a minimal amount of data entry with unique data, I thought the indexing should happen fairly quick…

After a few hours it was apparent something was not correct.  In the Configure Search Settings page, from within managing shared services - The indexing 'full crawl' was still in progress with no items yet in the index.  To resolve this I clicked in to the content sources and crawl schedules, and stopped any currently-running crawls.  Then I went back to Configure Search Settings.  From here I chose the 'Reset all crawled content' option.  Had this been a mature system, I would have had to use this with a bit more caution.

Once the 'Reset all crawled content' command completed, I initiated a new Full Crawl on the Content Sources and crawl schedules page.  Within a few minutes, the crawl had completed with a few thousand indexed items.  Even better, my searches were finally returning items!

The other day I was faced with the task of automating some IIS logs via an FTP scheduled task.
In order to do this, I relied on Rov Van Der Woude (www.robvanderwoude.com) and the following script to get me going:
http://www.robvanderwoude.com/batexamples_y.php
Before the subroutines kick-in on the file, I changed a couple settings to get the format that the IIS logging was setup for. I'll use W3C in this case (exyymmdd.log) where ex and .log remain static.
The portions in bold are what was added or changed:
:: Add leading zero to YesterD if necessary
IF %YesterD% LSS 10 SET YesterD=0%YesterD%
:: Yesterday's Year in YY format
set YesterY=%YesterY:~-2%
:: Yesterday's date in YYMMDD format
SET SortYest=%YesterY%%YesterM%%YesterD%
REM SET SortYest=%Yesterd%%YesterM%%YesterY%



:: Display the results
REM ECHO Format: DDMMYY (%LocalFormat%)
REM ECHO.==================================
REM ECHO Today: %SortDate% (%Today%)
CALL ECHO %SortYest%
:: Done
ENDLOCAL
GOTO:EOF
This was complimented by a few tweaks to the bat file, and the following guy: http://www.marijn.org/archive/2006/batch-files-variables
In particular, the step used is:
---------------------------
@FOR /F "tokens=*"%%i IN ('whateverYourFileIsCalledMaybeYesterday.bat') DO set yesterday=%%i
Echo %yesterday%
----------------------------
That echo is only necessary for testing. Once you are happy with the function of the script, then remove the echo line.
This was half the battle. I now have this wonderful script that is going to give me yesterday's date. Now I just need to feed this date in to the FTP script. Hrmmmm… I scratched my head at this for a bit, and got quite frustrated that FTP doesn't directly support batch variables. Alas, the work was not in vain. Below is the resulting file content of RunThisTask.bat that gets called by TaskScheduler each day:
--------------------------------------
@ECHO OFF
@FOR /F "tokens=*" %%i IN ('yest.bat') DO set yesterday=ex%%i.log
REM The above command takes the resulting variable created from yest.bat and puts it in the
REM format of the W3C IIS log naming convention.


echo %yesterday%
> temp.ftp ECHO open ftp.myFTPsiteToSaveLogsTo.com
>>temp.ftp ECHO username
>>temp.ftp ECHO password
>>temp.ftp ECHO lcd T:\YourIISWebLogDirectoryForOneWebsite
>>temp.ftp ECHO put %yesterday%
>>temp.ftp ECHO quit
REM The above creates a file temp.ftp in C:\ftp2govmetric (or where the batch file is called)
REM The following ftp logon, directory change, and put command transfer yesterday's log file
REM to the govmetric ftp site
ftp -s:temp.ftp
del temp.ftp
REM The above calls the created temp file that FTP reads in (FTP doesn't do variables directly)
REM After the FTP session completes, the temp file is then deleted, and the transfer scheduled task is complete
-------------------------------------
The first line after the ECHO is where the static parts of the filename get appended (ex and .log) to the calculated date. Of course, if the system time ever goes out of whack, then this script will fail miserably.
Security - There is none! this solution is using only the built-in windows 2003 technology to achieve this result. If the receiving server can handle SFTP then use that! Note the password you use with FTP is in plain text. You can lock-down the directory where these scripts are stored with NTFS permissions, which should suffice for this purpose as you need a user with admin rights to kick-off the Task Scheduler as well (so either the Administrators Group or the user running the task is who to whittle permissions down to).

Team Foundation Server 2005 Workgroup

What an aboslute beast of a child!

I now have the displeasure of installing this development environment. The nice thing about the installation is the installation guide. The steps involved are in my opinion, second-rate for a multi-billion dollar company.

The requirements are laid out fairly well. You need:

Server 2003 (check)
IIS 6 with ASP.NET (check)
SharePoint Services (doc didn't work for me here)
SQL 2005 (no SP worked for me, applying it afterwards)

The main caveat for anyone attempting to install, is to follow the guide, and utilize the different accounts for their roles, or you will run in problems while installing.

One feature I do like is how the pre-installation checks take place. These need to go much further though. For example, you need IIS to be freshly installed, that means no Virtual Server or any other website installed. Virtual Server 2005 R2 is at least kind enough in their installation steps to warn you of the potential issues installing on other than the default website will cause. Quite simply, Team Foundation web tier (unless you are an absolute whiz on IIS 6) demands sole existence.

The other issue I had was with the SharePoint installation. While it's easy enough to appreciate you must manually install sharepoint so as to not use MSDE, make sure you don't make any configuration changes on the default admin website or again, you will have to start from scratch. The same goes for the reporting services, don't touch it, no matter how much you think you may need to for permissions or whatever. The Team Foundation installation will handle all of it. What I found perplexing is while the default installation of Sharepoint Services 2.0 SP2 worked fine, when I tried to install Sharepoint Services 3.0 (and yes folks, 3.0 is listed in the installation manual), the Team Foundation installation demanded SharePoint Services 2.0 with SP2! This was the only descrepancy I found in an otherwise well-written installation document.

Once the installation completes with success, you are not given much direction as for what to do next. In order to now actually use this, one must have the Team Explorer application installed/added in to their existing Visual Studio 2005 setup. This is done by using the Team Foundation Server setup program, and selecting that option.

After the installation completes the first step is to add users/groups to the foundation server, using the account you installed with, on the foundation server. Open Visual Studio, then click on the newly created Team menu item. From there you navigate to Team Foundation Studio Configuration, then go to groups. The interface here is pretty self-explanatory. You add the users/groups for permissions to the default security groups or create your own. All should then work, right? Wrong. For users to use Team Foundation Workgroup (standard requires purchase of its own license), each user must be individually added to the Licenses group. That original user for installation will appear here (that's who you're logged in to get to this point). Once you add at least one other administrator, you can then log out, use the new administrator, then remove the installation account to make use of all five licensed connections.

Once the installation finally goes ahead, everything runs fairly smooth. In conclusion, I found the installation to have some very positive areas, and some areas that could build upon the Virtual Server installation scenario. It was a bit like having a family member refuse to sit and eat at the dinner table because the plates/forks/etc were not set to their liking.

Virtual PC Time Synchronization

Today I received a question on how to disable the VM time synch with its host. The answer for this is not as straight-forward as it is with VMWare.

http://blogs.msdn.com/virtual_pc_guy/archive/2007/11/28/disabling-time-synchronization-under-virtual-pc-2007.aspx

In short, adjust the .vmrc xml file to include the following tags (under mouse is fine)



false



At least it is in XML

Remotely Logging Off Terminal Service Users

This guy has a contrite posting on the matter:

http://www.danrigsby.com/blog/index.php/2008/08/26/remotely-log-off-remote-desktop-users/

Ready, IPSEC, No Communication

That was the problem I had recently experienced with the application of updates MS09-045 and MS08-049 in tandem. The machine this took place on also doubles as an EndPoint Security Server (which invites its own slew of issues).

The handy work of Ant Drewery at http://www.drewery.net/blog/2006/04/18/failure-of-ipsec-services/#comment-40309 helped send me in the right direction. Looks like petri may have some competition!

The issue occured after trying to restart the machine after installing updates. For whatever reason, the system just did not want to bounce. Despite about 3 attempted restart /f commands. Upon it coming back up, there was no network connectivity to the outside world. IPSEC had ceased all that communication quite nicely.

To resolve - I re-registered a dll with the following command:

regsvr32 polestor.dll

Upon restart all works nicely! This is on a 2003 SP2 client with a 2003 SP2 Domain Controler.

More IIS 6.0 Fun

Several months ago, I set up a new network environment that was not live at the time.  That environment, once up and running and ready, was then utilized by some outside consultants and developers as an ad-hoc testbed.  Ultimately, The work carried out was not entirely (I am starting to doubt this every happens) removed or cleared up, so the system was back in its original state.  Luckily (or smartly), a complete backup of the system state, the IIS metabase, and the IIS configuration and directoy structures were made before access was given.  This allowed me two options:

 

1) Figure out what got changed and how to undo those changes

2) Restore the system settings, configuration, metabase, and directory structure.

 

Time not being of the essence, I chose the former.

 

When websites utilize an anonymouse user, that user can either be the default (IWAM?) user, or any other user you choose to specify in either a domain or local machine.  When this happens, or if any other site on IIS, or Virtual site utilize a non-default anonymous user, this poses frustrating authentication problems.  There are two ways (maybe three, but I didn't have any luck with the adsutil.vbs approach of synchronizing the passwords) that I was able to resynch the ever-changing anonymous user password hash.  The first is to route out all descrpencies for each and every incarnation of the mismatch for the user in the metabase (Make sure you are able to edit the metabase directly if you want to try this dicey approach.

 

The more-straight-forward approach that is much much safer to use is to disable all authentication for each website and virtual website.  Once that is done, you can go back and start enabling the anonymous authentication.  What is happening underneath the hood, is you are allowing IIS to automagically handle all the password hashes on the metabase by removing them.  Then as you re-enable this for each website or Virtual website, IIS will automatically ensure the passwords are synchronized when you select the other sites in the Apply Changes Prompt.

 

What causes them to get out of synch!?

 

This, thus far in my experience is not terribly easy to explain.  From what I can gather in the limited testing I have done, lets say you have siteA and virtualSiteA.  If you disable the synchronization on siteA then later re-enable it, you need to select any and all virtual sites when prompted to apply the authentication changes to.  If this doesn't happen, then oldest password hash (now virtualSiteA) is going to have the only legitamite hash to authenticate against, and the rest of your sites will not operate the way you want/need them to.

 

So, before you go out and start messing with Application Pools, or deleting and recreating users, try the above (no warranties!  Use entirely at your own Risk!).

SQL Data Types

So now that I'm studying for my 70-431 exam fully, I am writing out the datatypes:

 

• Exact Numeric (Used for precision data)
• Approximate Numeric (Used rarely, and appears to me to be a hangover from C)
• DateTime
• Money
• Character
• Binary  (this includes the image type most likely usedin Sharepoint for storing documents)
• Specialized (identity for primary keys, GUIDs, are two examples here)

Constraints:

• Check Constraints (These are set on tables)
• Rules (These are being phased out if not already in 2008, do not use), can be used outside of a table
• Unique Constraints (Prevents duplicate values in columns)
• Default Constraints
• Primary Key
• Foreign Key (this constraint ensures the value exists in another table already)