MOSS delivers a Records Center site template which can be used for records managment, but once this is configured every user in the farm will be able to send documents to Records Center by using the context menu Send To -> Records Center. This is usually not desired since enterprise would normall develop a systematic way of submitting records through workflows, event handlers, etc.
To hide Send to Records Center menu option, I've listed out 2 options.
Option #1: quick but need to watch out for SP install to avoid changes being overidden.
1. Go to c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\1033, locate CORE.js, make a copy of the file and save it in another place for backup purpose.
2. Open core.js in Notepad, search for "officialfilename" and comment out the line that says "CAMOpt" in the "if block" by inserting "//" in front of the line. Save the file. The code should look like the following after the change:
if (ctx.OfficialFileName !=null && ctx.OfficialFileName !="")
{
strDisplayText=ctx.OfficialFileName;
strAction="STSNavigate('"+ ctx.HttpRoot+ "/_layouts/SendToOfficialFile.aspx?"+ "SourceUrl="+ currentItemEscapedFileUrl+ "&Source="+ GetSource()+"')";
strImagePath="";
//CAMOpt(sm, strDisplayText, strAction, strImagePath);
}
3. IISReset to force client cache refresh.
Option #2: more deployable and can control which sites the change is applied to.
1. Go to c:P\rogram Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\1033, locate CORE.js, open core.js in Notepad, search for "officialfilename". Copy the entire javascript function and paste it to a new file called something like CORE_custom.js and make the same changes as in option #1.
2. In SharePoint Designer, open the site where you want the change to be applied. Create a custom master page with the following change:
<SharePoint:ScriptLink language="javascript" name="core.js" Defer="true" runat="server"/>
<SharePoint:ScriptLink language="javascript" name="core_CUSTOM.js" Defer="true" runat="server"/>
3. In your site, go to site settings and Master Page, then apply the custom master page.
How to start an Approval workflow programmatically in the InfoPath form code?
- Create a web reference that points to http://yourSiteUrl/_vti_bin/workflow.asmx .
- Configure an Approval workflow in your form library and capture the template id.
From form library settings->workflow settings, click the workflow name, right click in the page to View Source. Search for “templateid”. The TemplateID looks like the following:
TemplateID=%7b5C65AB69-11BC-430D-B730-71050250F576%7d
(“%7b” is encoded for “{“ and “%7d” is encoded for “}”)
GUID for the template id is : 5C65AB69-11BC-430D-B730-71050250F576
- Write the InfoPath code. The highlighted parts in the sample code below needs to be replaced.
**TIP: If you can't get the workflowParamers XML string right, you can write a simple console app in server using OM. SPWorkflowAssociation.AssociationData will return the init form data that you already configured in the list/library workflow settings.
public void submit_OnClick(DocActionEvent e)
{
// Write your code here.
WorkflowService.Workflow workflowService = new WorkflowService.Workflow();
workflowService.Url = "http://siteURL/_vti_bin/workflow.asmx";
workflowService.Credentials = System.Net.CredentialCache.DefaultCredentials;
workflowService.PreAuthenticate = true;
try
{
XmlDocument workflowParameters = new XmlDocument();
string strXml = "<my:myFields xml:lang='en-us' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:my='http://schemas.microsoft.com/office/infopath/2003/myXSD'><my:Reviewers><my:Person><my:DisplayName>Approver’s display name</my:DisplayName><my:AccountId>domain\\account</my:AccountId><my:AccountType>User</my:AccountType></my:Person></my:Reviewers><my:CC></my:CC><my:DueDate xsi:nil='true'></my:DueDate><my:Description></my:Description><my:Title></my:Title><my:DefaultTaskType>1</my:DefaultTaskType><my:CreateTasksInSerial xsi:nil='true'></my:CreateTasksInSerial><my:AllowDelegation>true</my:AllowDelegation><my:AllowChangeRequests>true</my:AllowChangeRequests><my:StopOnAnyReject xsi:nil='true'></my:StopOnAnyReject><my:WantedTasks xsi:nil='true'></my:WantedTasks><my:SetMetadataOnSuccess xsi:nil='true'></my:SetMetadataOnSuccess><my:MetadataSuccessField></my:MetadataSuccessField><my:MetadataSuccessValue></my:MetadataSuccessValue><my:ApproveWhenComplete xsi:nil='false'></my:ApproveWhenComplete><my:TimePerTaskVal xsi:nil='true'></my:TimePerTaskVal><my:TimePerTaskType xsi:nil='true'></my:TimePerTaskType><my:Voting>false</my:Voting><my:MetadataTriggerField></my:MetadataTriggerField><my:MetadataTriggerValue></my:MetadataTriggerValue><my:InitLock xsi:nil='false'></my:InitLock><my:MetadataStop xsi:nil='true'></my:MetadataStop><my:ItemChangeStop xsi:nil='true'></my:ItemChangeStop><my:GroupTasks>false</my:GroupTasks></my:myFields>";
workflowParameters.LoadXml(strXml);
//Guid for the workflow templateId
Guid guid = new Guid("{5C65AB69-11BC-430D-B730-71050250F576}");
//form URL needs to be replaced
XmlNode result = workflowService.StartWorkflow("http://siteURL/formlibrary/test.xml", guid, workflowParameters);
if (result != null)
thisXDocument.UI.Alert("Result: " + result.Value);
}
catch (SoapException ex)
{
thisXDocument.UI.Alert("SoapException: " + ex.Message + " " + ex.Detail.Value);
}
catch (Exception ex0)
{
thisXDocument.UI.Alert("Exception: " + ex0.Message);
}
}
VeriSign code-signing certificate comes as 2 files including 1 certificate file (.spc) and 1 private key file (.pvk). The following describes what we had to go through at my customer to digitally sign the InfoPath form template which has the Full Trust level set.
1. Download pvk2pfx.exe tool and run the tool to generate pfx file
http://msdn2.microsoft.com/en-us/library/aa906332.aspx
pvk2pfx -pvk mypvkfile.pvk -pi mypasswd -spc myspcfile.spc -pfx mypfxfile.pfx -f
2. Import pfx file into Current User's Personal Certificate store
Start->Run, mmc
From File, select add/remove snap-in
Add Certificates, when prompted, select Current user account
In the Personal node, select Certificates
In the details pane, select All Tasks->Import, go through the wizards to import the pfx file from step 1 and install to Personal store.
Now the VeriSign certificate should appear in the Personal Certificates store.
3. Sign the InfoPath form template
Open the form template in design mode.
From tools->Form Options->Security and Trust
Select Full Trust and Check Sign the form template
Click Select Certificate, now you should see the VeriSign certificate. Select it and click OK.
4. Republish the form template to the SharePoint form library.
5. Open the form from within SharePoint form library as the end user and now you should be prompted with warning about the publisher. Check "Always trust documents from this publisher" and click Open. The form should open.
Customer creates a Records Center site collection as a centralized place for archived documents and they don't want to include archived documents in the global search results (All Sites search) even when the user has the right permission to access these documents, but the content should still be available if user goes to the site and does a local search there (This Site search).
Also customer uses single SSP, single Web Application for Records Center site collection and Portal. Creating a separate SSP for this scenario is a little bit overkill.
I did some research and seemed like most of the search settings are all global like Crawl Rule in Search Settings in SSP admin, Search Visibility in Site Administration, etc. If I exclude this site collection from being crawled, then I can't search locally from within Records Center site either.
Eventually a Search expert directed me to the right place and the solution was quite simple actually. It should apply to many other common scenarios when you want to hide certain site collections from global search while not their own local search.
Here's the solution:
- In SSP admin->Search Settings, select View Scopes
- Select All Sites to enter Scope Properties and Rules page
- Click New Rule to create a new rule
- Check Web Address for Scope Rule Type, enter path to the site collection you want to exclude, for example http://server/sites/recordscenter
- Check Exlcude for Behavior
- Click OK to save.
- Go back to Search Settings and start a full crawl
- Now go to the Portal, with All Sites selected for the scope in Search Box, type some keywords to test (for example something you know exist in the site excluded from the scope). Make sure items contain that keyword do not display here
- Now browse to the site http://server/sites/recordscenter, with "This Site" selected in scopes dropdown in the search box, type in the same keyword from previous step and make sure the items contain that keyword do display here.
Came across Andrew's post about how to create a custom timer job in MOSS. I'm working on a Lotus Notes application migration project and I'm planning to recreate some Lotus Notes application Agents (scheduled jobs and notifications) in MOSS using custom timer job. Will post follow-ups on this later...
http://www.andrewconnell.com/blog/articles/CreatingCustomSharePointTimerJobs.aspx
Issues found this Andrew's timer job:
- I used the wsp file that Andrew provided and deployed to my customer's MOSS dev environment successfully but got Unknown Error when trying to activate the feature through Site Settings->Site Collection Features UI. The event viewer showed the insufficient permission to write to SharePoint_config database, etc. Then I performed stsadm -o activatefature -id ##### -url http://server/sites/siteName through command and it worked.
- Sometimes changes made to the code were not reflected till the SharePoint timer service was restarted.
Itay has blogged the exact steps and screenshots on how to display current user info (email, full name, manager, etc) in InfoPath form by calling UserProfileService.asmx in MOSS 2007, most importantly without writing any code!
http://blogs.microsoft.co.il/blogs/itaysk/archive/2007/04/05/InfoPath-_2D00_-Get-the-current-user-without-writing-code.aspx
Note:
I was getting the following error during my first try:
The query cannot be run for the following DataObject: GetUserProfileByName
InfoPath cannot run the specified query.
The SOAP response indicates that an error occurred on the server:
Server was unable to process request. ---> Attempted to perform an unauthorized operation.
Cause: I was calling the web service against the server root that I didn’t have access to. For example http://server/_vti_bin/userprofileservice.asmx but I didn’t have access to http://server
Solution: Call the web service against the site the InfoPath template lives in, which the current user has access to. For example http://server/sites/sitename/_vti_bin/userprofileservice.asmx
People alway ask how to use their own 404 file not found error page vs. the generic one from IE in MOSS environment. The following example catches the 404 error and sends users to a redirect page.
Here's the steps:
1. In your MOSS server, make a copy of
%systemdrive%\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\1033\sps404.html
and call it my404.html
2. Create a Virtual Directory in IIS under your MOSS root web application. For example /errors
3. Create your own redirect aspx page, for example /errors/my404redirect.aspx and code your redirect logic in there. This is a normal asp.net page.
4. In my404.html, make the following change:
STSNavigate("/errors/my404redirect.aspx?oldUrl=" + requestedUrl);
5. Create a Console Application and insert the following code and run it in MOSS server
System.Uri webApplicationUri = new Uri(http://MyMOSSServer/);
SPWebApplication webApplication = SPWebApplication.Lookup(webApplicationUri);
webApplication.FileNotFoundPage = "my404.html"; //*note
webApplication.Update();
*Note: By default this is set to null. FileNotFoundPage needs to point to a html file that lives in %systemdrive%\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\1033. The file needs to be html only.
6. Now when you browse to a page that doesn't exist, you should expect to be brought to the redirected page.
*Another note:
In IE there's a "Show friendly HTTP error messages" setting which is ON by default in Internet Options->Advanced. With this setting on, sometimes your custom error page is not displayed. In order to override this setting, both my404.html and /errors/my404redirect.aspx from the above steps need to be larger than 512 bytes in size. Refer to the following KB about this setting: http://support.microsoft.com/kb/218155
* This seems to be working within a site collection context only, i.e. http://MyMOSSServer/sites/siteA if sites is a wildcard inclusion managed path and siteA doesn't exist in MOSS then this URL will NOT trigger the custom 404 error page set to SPWebApplication.FileNotFoundPage property.
A customer is looking to migrate their SPS 2003 content to MOSS 2007 and also restructure their sites during the migration process.
None of the standard upgrade approach from Microsoft would accomplish that and I've been evaluating some partner solutions that support content migration from WSS V2/SPS 2003 to WSS V3/MOSS 2007. The following 2 products have been evaluated and compared based on the trial download and information I received from the indivisual product sales/support/bussiness dev team.
|
|
Tzunami Deployer 2.01 |
DocAve 4.1 Migrator |
|
Technology |
Client
· .NET-based Windows application
Server add-on:
· Web service/OM on MOSS servers
|
DocAve server:
· Database service
· Network service
· Tomcat service (java-based web server)
DocAve media server:
· Media service
· Patch service
DocAve client:
· Communication service (Web service/OM)
DocAve database:
· Builtin – MySQL
· Or existing SQL Server
Browser access:
· Hosted by Tomcat (http://server:8080/docave) |
|
Remote access |
Windows application running on remote desktops |
Browser access supported with username/password |
|
Installation components |
- Client on remote desktop
- Web service on MOSS servers
|
- Server on any machine
- Client on SPS 2003 web-front end servers
- Media server also required.
|
|
Site level and item level migration |
Yes |
Yes |
|
Modified time and Modified by |
Preserved |
Preserved |
|
Create a new site in target on the fly |
Yes (Collaboration Portal and Publishing Portal not available, need to exist already) |
No (target sites need to exist already)* Updated in 2/1/2007 release. Now target sites can be created on the fly in 2007 |
|
Support migration from sites based on custom sitedef |
Yes |
Yes |
|
User permissions required |
Farm admin rights, etc (workaround - offline support for non-admin users and then commit to SharePoint by admin) |
Special power user rights granted by using Control Panel in the software |
|
Migration sources supported |
· File Shares
· SharePoint Portal Server 2001
· WSS V2/SPS 2003
· Exchange Public Folders (mail items, files, discussions, contacts, appointments, etc.)
· Lotus Notes
· EMC Documentum and eRoom
· Hummingbird
· OpenText Livelink
· Plumtree
· Hyperwave
· Custom repositories
|
· SPS 2003
· Exchange Public folder |
|
Touch databases |
No |
No |
|
Migrate views |
No (available in later version) |
Yes |
|
List types supported for migration |
All list types |
· List securities not preserved
· Discussion board pending
· Survey pending (Update: surveys are now supported 5/12/07) |
|
Schedule migration task in UI |
No |
Yes |
|
Pricing model |
- based on content size + maintenance fee
|
· base price + price per SPS 2003 user |
Note: everything listed aboved is based on personal evaluations done before 3/13/2007 and information is subject to change. Please always refer to each product web site for the updated product information.
Tzunami Deployer: http://www.tzunami.com/products/?did=11
DocAve Migrator: http://www.avepoint.com/products/sharepoint-migration/
Right before the scheduled time for production upgrade from SPS 2003 to MOSS 2007, my customer's SPS 2003 production environment was down. The database server was running on SQL Server 2000. The DBA told us ALL the SharePoint datababases just disappeared overnight and they didn't have any script to track who deleted them or it's virus or some other kind of intrusion (unbelievable?!).
Anyway, I was asked to help with restoring the SPS 2003 farm using all the database backups including the CONFIG database, but restoring a CONFIG database doesn't work most of the times since it can be easily out of synch with the content databases (refer to the SPS 20903 resource kit http://www.microsoft.com/technet/windowsserver/sharepoint/V2/reskit/c2861881x.mspx ). That's also my customer's case. They were seeing all kinds error message when trying to navigate through portal site - "invalid configuration database (offline)", etc. So there's no point of trying to fix that, we just decided to rebuild the configuration database in stead.
The following steps decribe how I restored the SPS 2003 from the SQL databases that were restored from the backups in the tape:
- Disconnect all the servers from the farm
- Configure the configuration database with a new name Portal_Config_New
- Add back all the servers in the farm pointing to the new configuration database
- Unextend the Virtual Server your portal site resdies using Remove Windows SharePoint Services from Virtual Server in Central Admin. Note: if your Virtual Server has been extended, trying to restore a portal site will fail with error complaining the VS has been extended.
- In the SPS admin, click on Create a Portal Site
- Select Restore a portal site
- Type in your portal content database, profile database and service database. In my case they were in the format of portal_SITE, portal_PROF, portal_SERV.
- Submit the above and the portal site should be restored. Note: if you have already added your portal content db back to the farm the restoring a portal site will fail with error message complaining the site/database already exists. Delete the portal content db from Manage Content Databases and repeat steps 4-6
- After Verifying the portal site is up running, add the rest of content databases using Manange Content Databases from your Central Admin site.
- Verify your portal and other team sites.
- Note: You may have to redeploy custom web parts or other applications that you had under the Virtual Server, but since my customer was going to upgrade to MOSS and retiring the SPS 2003 environment soon, they were ok with not redeploying. They just wanted to keep the SPS 2003 environment for post-upgrade comparison.
During my customer's migration from SPS 2003 to MOSS 2007 testing environment, we encountered some challenges while migrating My Sites. With Bill's help, I was able to fix the My Sites in testing environment. During the actual production upgrade, My Sites were sucessfully migrated.
Here's a recap of the fix I did in the MOSS testing environment:
1. Migrate the portal content db first.
stsadm -o addcontentdb -url http://sharepoint07uat.corproot.com/ -databaseserver dbserver -databasename portal_SITE
2. Create a web named something like “my” using My Site Host template under the portal
stsadm -o createweb -url http://sharepoint07uat.corproot.com/my -sitetemplate SPSMSITEHOST -title "MySite Host"
3. Then restore SSP from the old PROF db:
stsadm -o restoressp -title Restored_SSP -url http://adminserver:11111 -ssplogin DOMAIN\sharepoint -mysiteurl http://sharepoint07uat.corproot.com/my -indexserver
indexservername -indexlocation "d:\index” -keepindex -sspdatabaseserver dbserver -sspdatabasename portal_PROF -ssppassword pwd
4. Execute iisreset
Then go into the SSP admin, check My Site settings, search settings, User profiles to make sure they all look good.
5. Now as a user, when I click on My Site in portal home page, I’m brought to http://sharepoint07uat.corproot.com/personal/userid and when I click on My Profile (or others click on my name) I’m brought to http://sharepoint07uat.corproot.com/my/person.aspx?accountname=DOMAIN\userid
6. To see the old SPS2003 MySite home page, just type http://sharepoint07uat.corproot.com/MySite . The Web Part error in this page is expected due to the retirement of My Alerts summary web part in MOSS 2007. Other web parts from your old MySite home page should show up here. This link can be pinned at either SSP or site level.
I'm also linking Bill's blog here for further reference:
http://blogs.technet.com/wbaer/archive/2007/02/19/co-hosting-team-and-personal-site-collections-within-an-individual-web-application.aspx
Earlier I saw one crawling error in my customer's new MOSS environment after upgraded from SPS 2003. It's not necessary related to the upgrade though.
I saw the following error in the crawl log:
sps3://domain.company.com
Exception from HRESULT: 0x80040E2F (Exception from HRESULT: 0x80040E2F)
From the event viewer on the index server:
The start address <sps3://domain.company.com> cannot be crawled.
Context: Application 'sharedservices1', Catalog 'Portal_Content'
Details:
Value violated the integrity constraints for a column or table. (0x80040e2f)
I just found out there’s potential issue when there’s a SQL maintenance plan in place that rebuilds the indexes including SharePoint 2007 databases. The error we saw earlier about integrity violation (0x80040e2f) may occur after the SQL maintenance plan changes the index properties that SharePoint expects to be in place.
I would suggest that you change your SQL maintenance plans to exclude the SharePoint databases from receiving an Index rebuild. At least until more guidance is available from Microsoft on how to use SQL Maintenance and SharePoint 2007.
Our product team have reviewed the SQL maintenance tasks and have made the following recommendations.
Tasks Considered Safe
- Check DB Yes
- Shrink DB Yes
- Reorganize Indexes Yes
- Cleanup History Yes
- Update Statistics Yes but unnecessary since timer service does this automatically.
- Rebuild Indexes No, if the task that ships with SQL 2005 management studio is used. Using scripts that restore all options is allowed.
Although this known issue seems to the cause of my customer's crawl error but before we tried contacting the Premier support for a fix, we worked around the issue and now the crawling and people searching are working just fine :-).
The trick we did was:
Delete the existing People scope from Search settings, re-create a new People scope using the exact same settings as before. Restart the full crawl. The People scope should display a non-zero number of items. When it failed, it displayed 0 items in the View Scopes area.
The maintenance plan issue is still a good thing to know for future reference and I would try to pay attention to additional advice from Microsoft for this.