SharePoint Services WSS 3.0 + Windows 2003 R2 + indexing / searching broken?

The problem of search and or indexing that is broken on a Sharepoint site running on a Windows 2003 R2 box, had a bazillion different "solutions". I searched everywhere on the net for a way to fix this annoying problem. Nothing seemed to make it work. I finally lucked out (on my n-th attempted of fixing this) and came across this blog entry:

http://mysharepointblog.com/post/2007/01/Windows-SharePoint-Services-%28WSS%29-30-Search-Setup-Notes.aspx

I have no idea why the indexing died in the first place, but since I'm not a huge fan of the product in the first place (I'm a Google Apps fanboy!), I'm just going to notch it down to inherent complexity of Sharepoint and leave it at that! Lucky for my client, they are just using Sharepoint for their intranet and not their main file store!

Nexenta + NDMP Backup with BackupExec 12.5 + low free space issues

NexentaStor has been lots of fun to work with, there are still a few hickups as mentioned earlier in my blog, but it is turning out to be a pretty cool solution for clients that are not wanting to throw down big bucks on boutique NAS/SANes during this recession. Oh, and do I hear de-dupe is around the corner for ZFS?! :)

I was experimenting around with the NDMP Backup options in NexentaStor. I enabled the service, and punched in the details of our Symantec BackupExec 12.5 server, with NDMP option enabled.

Not being really familiar with this option in BackupExec, I just set everything pretty much with the default, and unfortunately, when browsing for backup devices, Nexenta does not appear in the NDMP devices, so off I went and logged a support ticket with Nexenta.

Here is their response, not holding my breath, but it would be seriously kick ass if NDMP backups did work with BackupExec (not to mention would get great speed, and can point backups to "latest" folders within a special backup snapshot for example - nice point in time backups/archives to tape!)

Looks like we do not have many customers using BackupExec. In general, this is our policy to support 3rd party software only if there is enough evidence that this is either a standard, or used by a significant number of users (which would make it de-facto standard). BackupExec is neither. We may be able though to get to it after the next major release 3.0 planned for end of November, early Dec.

Now onto free space in NexentaStor. I do encourage you to keep a close eye on available space on your volumes. We were in a situation where a slight mistake in a rsync script, filled up our Nexenta box. We had on or less than 10% space left, and it ended up with some strange behaviour.

Everything from no access via web interface, the console on the server locking up when trying to remove snapshots via the web interface, and errors and dead drives appearing after scrub jobs were issued (which weren't really dead drives!). After we blew away a bunch of stuff, and snapshots via command line (setup snapshot destroy), things settled down again.

I really like the weekly reports that the system can send to you, surf through them just to make sure available space is in check, and all should be fine.

pfSense - ftp server in DMZ / OPT interface - the userland FTP-Proxy setting

Had some fun setting up a FTP server, on a OPT interface on a pfSense router.

On the legacy router setup, we had Virtual IP for the ftp server. With this setup, we would put in a port forward to the ftp server in the DMZ, and everything would play nice.

With pfSense, you need to tweak some settings to get things happening.

After setting up my virtual IPs, and setting up some WAN rules, we couldn't connect to the ftp server via any interface. Problem turns out to be a combination of using the virt IP (as apposed to the primary IP of the WAN interface as the IP you are using to access ftp from the WAN side), and a little pfSense userland ftp-proxy setting

I sifted through some pfSense forum entries, and the following links gave me the clues:

http://forum.pfsense.org/index.php/topic,6218.0.html

http://doc.pfsense.org/index.php/FTP_Troubleshooting

So I went through things step by step, and as suggested:

1. remove all ftp rules (WAN side) I setup previously
2. removed the Virtual IP - I HAD to use the WAN interface primary IP address - the Virtual IP would NOT work - had to make an A record change and notify users of the change
3. went to Interfaces -> WAN -> unticked the Disable the userland FTP-Proxy application (also unticked on the other interfaces)
4. this auto created a WAN rule: * * * ext_WAN_IP 21 *
5. then added another WAN rule: * * * ftpserver_opt_IP 21 *
6. for users in the LAN, I made an internal DNS override for the ftp domain name to point to the ftp server's internal IP address - eg: ftp.blah.com -> 192.168.1.1 (normally on the net, it would point to the WAN interface primary IP address in the A record)

Took a bit of time, but finally sorted it out and now we are back to ftp serving via pfSense!

NexentaStor 2.0/2.1 + Windows 2008 SP2 FAIL

Last week, I went ahead and upgraded a client's Windows 2008 domain controllers from SP1 to SP2. Reason, I'm always staying ontop keeping their Linux based NAS boxes working nicely with Active Directory etc, and thought it was a quiet time to update stuff across the board.

As it turns out, once Windows 2008 was at SP2 level, the NexentaStor 2.0 box now doesn't work on CIFS shares. The only way to access them is to use the "guest" login (a login box appears when you browse to it from the network).

Viewing the CIFS server log - got this:

Aug 20 13:27:37 server1 smbd[352]: [ID 526780 daemon.notice] Failed to establish NETLOGON credential chain
Aug 20 13:27:37 server1 smbd[352]: [ID 871254 daemon.error] smbd: failed joining domain.lan (UNSUCCESSFUL)
Aug 20 13:27:37 server1 idmap[335]: [ID 694198 daemon.notice] Configuration unchanged

After sending an email to support, they pointed me to:

http://www.nexenta.com/nexentastor-relnotes - Scroll down to v1.1.9 - known problem

and http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6850508

I have been told this will be addressed in September... or we can roll back to SP1 on the domain controllers! WTF, I guess this is Sun that is just slow to move on a pretty big bug. :(

Set Trusted Local Intranet Zone - Trusted Sites - Group Policy + IE8 ADM

Getting the latest inetres.adm (IE8 ADM) setup on your domain controller/GPO:

First thing to do is install IE8 on the server.

Then locate the inetres.adm probably in the %WINDIR%\inf\ folder.

Edit your GPO for Internet Explorer settings (or create a fresh one if you don't already have one).

Expand Local Computer Policy, expand Computer Configuration

Right click on Administrative Templates. If you see Inetres template on this list, click Remove, and then click Close

Right click on Administrative Templates and click on Add/Remove Templates. Click Add and locate inetres.adm in %WINDIR%\inf\ and click Open to add it again.

Getting rid of the IE8 nag screens when signing into a new user profile - useful for Terminal Servers:

Computer Templates - Administrative Templates - Windows Components/Internet Explorer
Prevent performance of First Run Customize settings - Enabled (and go directly to homepage)

Setting up Trusted Zones for all your users on the network:

Edit your IE settings GPO (or create a new one) with the following -

Computer Configuration - Administrative Templates - Windows Components - Internet Explorer - Internet Control Panel - Security Page - Site to Zone Assignment List - Enabled

Then click the Show button - and add the appropriate Value Name and Value - eg: http://www.mysite.com with a value of 2 for Trusted Sites Zone, or 1 for Intranet Zone

NOTE: Users can not modify the list themselves, it is locked down via this GPO.