I am attempting to set up a test sharepoint server environment to deploy the current production environment. This will contain a copy of the prod sharepoint Content DB, and will reflect the same general conrfiguration:
-separate service account for Sharepoint content managment and Sharepoint configuration
-SQL DB server and Sharepoint web components run on separate OS instances
-Sharepoint installed on non-default IIS site, using host headers to direct users to the secondary IP (do we really need a secondary IP???)
I am having some difficulties around Kerberos auth and also with prod DB import. Here are some helpful links:
It seems that some of our constituients have not been paying overly much attention to the settings on their scanners. We have over 40Gb of black-and-white, text-only documents scanned at 24 BPP, uncompressed, consuming 10 Mb each!
This happened once before. My colleague Warren licensed a product called “2TIFF” to shrink the files in question. This works well, except in his case ALL of the images in an Application folder needed to be compressed. I only need to shrink SOME of them.
After much fooling around and wasting of time, I was able to use a win32 port of the UNIX “find” command to hunt down all of the large files, dump the list to a file, and then use this file as a source for 2TIFF. The big mess of images now occupies only about 30 Mb of space.
Here are the sommand syntax details:
> find.exe “I:OBJECTSPURCHASE_ORDERS” -size +3M -fprint bigfiles.txt
(searches the PURCHASE_ORDERS document tree for all files larger then 3 Mb, dumps results to the text file “bigfiles.txt)
> FOR /f %F in (bigfiles.txt) DO ( “C:Program Files2TIFF2tiff” s=%F d=%~dFshrink%~pF -namegen=”[name].[srcext]” -quantize8 -ct4 -cd4 -keepexif)
(Perform a loop operation. For each loop, set the next line in bigfiles.txt to the variable %F. Run the 2Tiff program using %F as the source file. Use shrink as the output directory (example: when %F=”c:objectsprocurement1163.bin, the output directory will be “c:shrinkProcurement1″).)
Here is what the 2Tiff arguments mean:
-namegen=”[name].[srcext]” -> The name of the destination file is the same as that of the source ([name] is a built in variable equal to the source file name. [srcext] equals the source file’s extention)
-quantize=8 -> sets the “quantization” level of the TIFF. This value effects the “sampling rate” and affects image quality. Eight is the maximum value, for best quality.
-ct4 -> Compression type “LZW” is used. This is the default type for color scans. We are using LZW rather than the standard “type 3” for B/W documents because tests showed that reducing these images to monochrome yielded very low quality in some cases. We are keeping some color information to allow anti-aliasing and thus better letter quality.
-cd4 -> Sets the color depth down to 4 BPP from the source 24 BPP. CD1 would be better, but as mentioned above, this results in poor readability of the destination TIFF.
-keepexif -> preserves EXIF tags in the destination file from the source. Probably there is no EXIF info in these files, but I thought we would keep it in case I am wrong.
Warren had used the “dither” switch, but IMNSHO this makes the target document look worse and also results in larger files.
Our server “SYSIMG1” just does not seem to want to take on its new role of replacement RIS server. I guess it just liked being a NetWare box and resents its lot in life.
Robocopy of the image library from \risprimereminst is consistently a failure. I run out of drive space every time, and the Gorveler never frees up enough drive space to resume copy operations.
I followed MS advice from the KB and have tried using our backup software (Legato) to restore the whole image partition to SYSIMG1 from RISPRIME. This generally caused BSOD errors on SYSIMG1. This particular problem cleared up after I patched the iSCSI initiator from v2.0.0 to v2.0.1, set the “lanmanserver” “binlsvc” (RIS Service) and “groveler” services to be dependent on “MSiSCSI” (the iSCSI initiator service), and also disabled a misconfigured secondary NIC on the server. Now I can restore the RISPRIME volume, but the groveler does not want to start.
So, I seem to have fixed that problem by “repairing” the SIS database on the volume… (where repair=deleted the damn thing, and let the Groveler start over). The article in question is here:
And here is the key information:
The SIS Groveler service database is stored in the hidden folder named SIS Common Store on each SIS managed volume. To rebuild the Groveler service database, follow these steps:
1. Stop the Single Instance Storage Groveler service.
2. Make a backup copy of the SIS Common Store folder contents to an alternate location.
3. After a backup copy of the folder contents have been made, remove all the database files in the SIS Common Store folder EXCEPT for the *.SIS and the MAXINDEX files.
4. Restart the Single Instance Storage Groveler service.
NOTE: I had to run RISetup prior to successful restart of the Groveler. All of the configuration settings for the groveler are set by RISetup. Once this is done, the gorveler restarts, and a new .mdb gets generated in the SIS directory.
I made some more changes to the script and installer package:
– Decided to converge on the “Administative Install” method for wrapping the patches into the installer. This prevents the installed SAV instance from interfering with the patch portion of the install script. Features like “autoprotect” were preventing “msiexec /p” from working. Also, msiexec /p seems just plain unpredictable if the system has not been rebooted. I just don’t feel like injecting actions into the “RunOnce” registry key, or attempting to force a reboot.
– Added “AUTOPROTECT=OFF” to the msi options portion of the setup.exe line in the install script. This will prevent the SAV autoprotect from giving us grief while installation completes.
– Used WinRAR options to extract archive files to a specified directory: %SystemDrive%SAVInst.
(this will cause a local cache of the install files to be maintained on the system)
(NOTE: We may wish to add a script line to delete the contents of this archive on reinstall)
– Mod the setup.ini file to contain a higher version number for the product being installed than the default (this should allow the setup.exe to install over existing SAV10 installs)
– Added an error logging option to the MSI options portion of the setup.exe line in the script (-le %SystemDrive%SAVInstinstall.err)
– Prefixed the setup.exe line with %SystemDriveSAVinst to force run out of the directory created by the WinRAR extractor.