Friday, October 30, 2009

Windows Explorer very slow when browsing SharePoint Libraries

This problem has been popping up sporadically over the past number of months and I was unable to pin it to a particular client or server version. I’ve seen it in Vista and Windows 7 clients and also on MOSS 2007 with SP1 and with SP2.

When opening a SharePoint library using the Windows Explorer, the user had to wait anything between 5 and 30 seconds for a reaction – opening documents caused the same delay. It was impossible to use effectively.

I still haven’t worked out exactly how this setting is related, but changing it seems to have done the trick. Under “Internet Options”-“Connections”-“LAN settings” I disabled the checkbox “Automatically detect settings” (see below). Even though this was not effecting all users, I pushed this setting out in a GPO – so far so good.




Windows Explorer must have been looking for configuration settings every time the user clicked on a folder

Resizing Samsung hard drives to fit controller size limits

If your hard drives are too large to be managed by your controller (in my case 1.5TB HDD with an adaptec SATA RAID SA2420 card, with 1GB per HDD max.) you can resize them using using the Samsung EsTool available here. All details on the same page.
To resize your disk use the SET MAX ADDRESS feature. After resizing, you will be able to use them with size limited controllers (of course you can restore the initial size if needed).

Wednesday, October 28, 2009

Delay SAN shutdown on power outage, avoid corrupt databases...

In my case the SAN I have will shutdown immediatly if a power outage is detected : and this cannot be changed.
My hardware : Dell EMC AX150 + APC Smart UPS 750
You cannot delay this shutdown through the NaviSphere software.
This is really annoying since the SAN hosts the Exchange databases (could have been SQL databases too).
When there is a power outage, the Exchange server doesn't have time to shutdown before the SAN turns off.... and this can cause database or logs corrupt...
In order to avoid this and since there is nothing I can parameter, I have added an intermediate UPS as shown below :

SPA and SPB are the 2 power supplies of the SAN

So my servers (connected to another UPS) can shutdown on a power outage (please read the shutdown scripts article) and then once the intermediate UPS battery is low (or you can parameter a delay too) it behaves like a power outage for the SAN+UPS and this one turns off too.

Wednesday, October 21, 2009

Forefront : enable FCS client to change settings

When setting up Forefront policies you may want to let some users/computers paremeter their Forefront client on their own.
I thought that enabling the "Only administrators can change Client Security agent settings" would work as each user is in the administrator group of his machine.

This doesn't work unless you change the protection settings (virus/spyware protection) and set them to User controlled :

This will allow users to set their own schedule.
If you want to set the default scheduled scan (everyday 2AM) to another value, change it while Virus protection is set to on and before changing it to User controlled.

Monday, October 19, 2009

UPS Scripts/Procedure : Shutdown a Linux server from Windows.

When running APC PowerChute on a windows server and executing a command script on some events like we saw previously, it can be necessary to shudown a linux server too.

  1. On your Windows server running PowerChute, create a folder (eg. C:\ShutdownScripts) and copy in it plink and puttygen that you can download here

    Puttygen will create ssh keys, and plink will execute a command on a remote machine using an ssh connection.

  2. Run puttygen and create a pair of ssh keys (public/private) using SSH-2 DSA / 1024 in the same folder. You will generate two files, and sshkey.ppk.

  3. Create a batch file locally (shutdownLinuxServers.bat) and add commands like :
    cd C:\ShutdownScripts
    @plink -T powerchute@mylinuxserver1 -i sshkey.ppk sudo /sbin/shutdown -h -P now
    @plink -T powerchute@mylinuxserver2 -i sshkey.ppk sudo /sbin/shutdown -h -P now

    This will ssh to your linux servers with the powerchute account to halt and shut them down .

  4. On the linux server(s) side, you will need to create a user account able to shutdown the server.

  5. Create the powerchute account :
    useradd -m -d /home/powerchute -g users -s /bin/bash powerchute

  6. In the home folder of the user powerchute (/home/powerchute), create a subfolder .ssh (rights 700), and add it a blank file called authorized_keys (touch authorized_keys) (rights 644)

  7. Copy the content of your in the file authorized_keys

  8. Append this command at the end of authorized_key, after the public key :
    from=myWindowsServer,command=sudo /sbin/shutdown -h -P now ssh-dss
    Where myWindowsServer is the DNS name or IP of your server running APC PowerChute.

    Your file authorized_key should look like this :
    ssh-dss AAAB3NzaC1kc3MAAACBAOEIj5Hm0ByaNObfUPhpboS0fONW9WqATYXjGi/wlmJipxBNo+//WooNdfeMN9bCqlbT7Z0eXfL+r4Xdmqp........svjduAB2mbQ== dsa-key-20091009 from=,command=sudo /sbin/shutdown -h -P now ssh-dss

  9. Edit the sudoers file :
    > visudo

  10. Search for this block and comment the last line :
    # Defaults specification
    # Disable "ssh hostname sudo ", because it will show the password in clear.
    # You have to run "ssh -t hostname sudo ".
    # Defaults requiretty <-- commented

  11. Search for this block and add the last line :
    # User privilege specification
    root ALL=(ALL) ALL
    powerchute ALL = NOPASSWD: /sbin/shutdown

  12. On your Windows server, add C:\ShutdownScripts\shutdownLinuxServers.bat to your APC PowerChute script (C:\Program Files\APC\PowerChute Business Edition\agent\cmdfiles\default.cmd)

Monday, October 12, 2009

APC PowerChute script for Windows servers

When using the APC PowerChute software you can (must) run a script to shutdown your servers before battery is too low.
On the PowerChute web page, select the events you want to run a script from.
Add the default.cmd (C:\Program Files\APC\PowerChute Business Edition\agent\cmdfiles\default.cmd) command file.

The default.cmd contains after a fresh install :

@echo off
rem Maximize for best viewing
rem This command file provides examples of proper command file syntax
rem Command Files run by PowerChute Business Edition must be placed in this directory.
rem Use the full path name of executable programs and external command files.
rem The @START command must be used to run executable programs (see example below).
rem For the @START command, path names that include spaces must be enclosed in quotes;
rem arguments for the executable must be outside the quotes. A double quote must
rem precede the quoted path name. For example, to execute a command file in
rem c:\Program Files\APC\PowerChute Business Edition\agent\cmdfiles called myShut.exe,
rem the following line should be entered in the command file:
rem @START "" "c:\Program Files\APC\PowerChute Business Edition\agent\cmdfiles\myShut.exe"
@echo on

Add some new commands at the end like :
@START "" "C:\WINDOWS\system32\shutdown.exe" /s /f /m \\myserver.mydomain.intra /c "APC Shutdown" /d 6:12

This will shutdown your server remotely, closing all open applications and with a warning message.
You can add other commands or batch too.

IMPORTANT : the powerchute agent service may not run with sufficiant privilieges, so it cannot execute a shutdown on a remote server. Usually it uses a local account.
You need to change it to use an AD admin account :

Wednesday, October 7, 2009

Prevent domain users to add computers to domain

By default, Active Directory allows domain users to add up to 10 machines to the domain.
If you want to prevent domain users to add machines to the domain, you cannot do it by GPO, since the only policy existing "Add workstation to domain" applies to Computers Configuration and not User Configuration.
You have to run ADSI edit from the administrative tools, roll down Default Naming Context, right click on your DC=mydomain, then properties :
Find the value MS-DS-Machine-Account-Quota and change it to 0 (10 is the default value).

Monday, October 5, 2009

“Access is denied” error when crawling content with SharePoint or browsing local server

When crawling your local SharePoint site you may receive the following error message:

Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)

This can happen even if the account has the necessary permissions to crawl the site. This error is caused by what is know as the “loopback check”. The loopback check is basically a security “feature” which won’t allow a local IIS website to be accessed using a FQDN. This prevents an attack from pretending to be local thus bypassing certain restrictions.

Unfortunately, it also prevents your crawler from accessing local sites if they are using a FQDN.

Microsoft offers two workarounds here. You can either turn off this behaviour completely (not recommended) or you can exclude your site from this check. Here is method 2 from the above link:

  1. Set the DisableStrictNameChecking registry entry to 1.
    • Locate and click the following key in the registry:
    • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters

    • On the Edit menu, click Add Value, and then add the following registry value:

      Value name: DisableStrictNameChecking
      Data type: REG_DWORD
      Radix: Decimal
      Value: 1

  2. In Registry Editor, locate and then click the following registry key:
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

  3. Right-click MSV1_0, point to New, and then click Multi-String Value.
  4. Type BackConnectionHostNames, and then press ENTER.
  5. Right-click BackConnectionHostNames, and then click Modify.
  6. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
  7. Quit Registry Editor, and then restart the IISAdmin service.

Friday, October 2, 2009

Changing domain and NIS on SUN Solaris clients

  1. Edit /etc/defaultdomain
    Set the new domain used when booting up :

  2. Set current domain name
    > domainname mydomain.intra

  3. Add your NIS servers to /etc/hosts

  4. Set your client as a NIS client :
    > /usr/sbin/ypinit -c
    Add your NIS servers here (eg : nisserv1.mydomain.intra).

  5. Bind your client to your NIS server :
    > ypbind

  6. Check your NIS server binding :
    > ypwhich

  7. Reboot

Important Be sure you did 1. ok, otherwise you won't be able to boot anymore (boot -s for single user mode, and then correct your /etc/defaultdomain file, then reboot again)

Update NIS maps, share automount files (linux)

If you need to share mounts coming from your NIS server automatically on multiple linux clients you will update the local auto.master with something like :

Usually auto. folder refers to a /folder. All NFS shares automounted through auto.folder, will be mounted in /folder.

For instance you create a /etc/auto.netShare on your NIS server including :
home -rw server1:/mnt/sdb2
data -rw server2:/mnt/sdc1
public -rw server3:/mnt/sdb1

In order to make available this file to clients, you need to edit the /var/yp/Makefile first.

  1. Search for "AUTO_MASTER = $(YPSRCDIR)/auto.master"

  2. Add a new line just below :
    AUTO_NETSHARE = $(YPSRCDIR)/auto.netShare

  3. Search for "all:"
    Add auto.netShare to the list (passwd group hosts rpc...). By default all are commented out.

  4. Search for :
    auto.master: $(AUTO_MASTER) $(YPDIR)/Makefile
    @echo "Updating $@..."
    -@sed -e "/^#/d" -e s/#.*$$// $(AUTO_MASTER) | $(DBLOAD) \
    -i $(AUTO_MASTER) -o $(YPMAPDIR)/$@ - $@
    -@$(NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@

  5. Add below the auto.master block :
    auto.netShare: $(AUTO_NETSHARE) $(YPDIR)/Makefile
    @echo "Updating $@..."
    -@sed -e "/^#/d" -e s/#.*$$// $(AUTO_NETSHARE) | $(DBLOAD) \
    -i $(AUTO_NETSHARE) -o $(YPMAPDIR)/$@ - $@
    -@$(NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@

  6. Then better do a clean up in /var/yp :
    > cd /var/yp
    > rm -rf ./group* ./binding/* ./hosts* mail* netid* pass* proto* rpc* services* mydomain*

  7. Build the maps containing the new auto.netShare file
    > make all
    Running /var/yp/Makefile...
    gmake[1]: Entering directory `/var/yp/mydomain.intra'
    Updating passwd.byname...
    Updating passwd.byuid...
    Updating group.byname...
    Updating group.bygid...
    Updating hosts.byname...
    Updating hosts.byaddr...
    Updating rpc.byname...
    Updating rpc.bynumber...
    Updating services.byname...
    Updating services.byservicename...
    Updating netid.byname...
    Updating protocols.bynumber...
    Updating protocols.byname...
    Updating mail.aliases...
    Updating auto.netShare...

    gmake[1]: Leaving directory `/var/yp/mydomain.intra'

  8. Check your auto.netShare is part of the NIS maps :
    > ypcat auto.netShare
    -rw server1:/mnt/sdb2
    -rw server2:/mnt/sdc1
    -rw server3:/mnt/sdb1

  9. Now you can update /etc/auto.master on all clients with :
    /netShare yp:auto.netShare

  10. And restart automount on the clients :
    > /etc/init.d/autofs restart

Then you can use /netShare/home, /netShare/data, netShare/public on all clients. These folders are mounted when accessed and released after a while.

Add a secondary NIS server (linux)

It's recommended to add a secondary NIS server to your linux network, since if the only one breaks down, users with a NIS account (all of them in most cases) won't be able to log on the linux clients anymore. Only the user root which is local will be able.

The master NIS server nisserv1.mydomain.intra runs the NIS service ypserv (/etc/init.d/ypserv)

  1. Install ypserv on the secondary server nisserv2.mydomain.intra, and make it start when booting.

  2. On the master nis server nisserv1, add nisserv2 to the NIS servers list /var/yp/ypservers : nisserv1.mydomain.intra

  3. Then build the NIS maps :
    > cd /var/yp
    > make all

  4. At this point, we have to construct a list of the hosts which will run NIS
    servers :
    >/usr/lib64/yp/ypinit -m
    nisserv12.mydomain.intra is in the list of NIS server hosts. Please continue to add the names for the other hosts, one per line. When you are done with the list, type CTRL+D : next host to add: nisserv1.mydomain.intra
    next host to add: nisserv2.mydomain.intra

    next host to add:
    The current list of NIS servers looks like this:

    Is this correct? [y/n: y] y

    We need a few minutes to build the databases...

    Building /var/yp/mydomain.intra/ypservers...
    Running /var/yp/Makefile...
    gmake[1]: Entering directory `/var/yp/mydomain.intra'

    Updating passwd.byname...
    Updating passwd.byuid...
    Updating group.byname...
    Updating group.bygid...

    Updating hosts.byname...
    Updating hosts.byaddr...
    Updating rpc.byname...
    Updating rpc.bynumber...
    Updating services.byname...
    Updating services.byservicename...
    Updating netid.byname...
    Updating protocols.bynumber...

    Updating protocols.byname...

    Updating mail.aliases...
    Updating auto.netShare...
    gmake[1]: Leaving directory `/var/yp/mydomain.intra'

    nisserv1.mydomain.intra has been set up as a NIS master server.
    Now you can run ypinit -s nisserv1.mydomain.intra on all slave server.

  5. Then check all maps are updated :
    > ypcat passwd
    > ypcat group
    > ...
    This will display accounts, groups... that are available through the NIS service. You can check information is the same as the one on the master NIS server (/etc/passwd, /etc/group...)

  6. Now on the secondary server nisserv2, edit /etc/yp.conf and set nisserv2 as the NIS server to use.
    domain mydomain.intra server nisserv2.mydomain.intra

  7. Update NIS files from the master NIS server
    >/usr/lib64/yp/ypinit -s nisserv1.mydomain.intra

  8. On clients :
    Edit /etc/yp.conf and set it to broadcast, so that it will be able to find another NIS if the current drops :
    domain mydomain.intra broadcast

  9. Update the NIS server to use :
    > /etc/init.d/ypbind restart

  10. Check the NIS server you use (it can still be nisserv1) :
    > ypwhich
Client machines will use one of both servers. If the one they use fails, restart ypbind and by broadcast they will find one available.