Just a quick blog to remind myself for some research I am doing.
We need to export existing Administrator Approved InfoPath forms and I came across this article:
In short, use STSADM to export a CAB and reimport using PowerShell.
As it is an older article soooo… just in case I lose it. The details are below:
Admin approved form from MOSS 2007 get deployed as features within the 12 features hive under folders named with GUIDs. These need special handling to be moved to SharePoint 2010. The following steps need to be performed.
a) Export the Admin approved IP templates using stsadm command.
using stsadm -o exportipfsadminobjects command export the IP forms to a CAB file.
b) Import this into the SharePoint 2010 environment using the Windows PowerShell 2.0 Import-SPInfoPathAdministrationFiles cmdlet.
c) Check if the files are imported correctly by browsing to the Central Admin –> Manage Infopath Form Templates.
Other useful resources I found in my research on this topic:
Details further usage and includes updating of data connection files associated with InfoPath forms.
The Update-SPInfoPathUserFileUrl Command will allow you to updates your data connections in InfoPath form templates (.xsn files) and universal data connections (.udcx files) where references in the current farm should be updated when content is migrated to a different farm URL.
Upgrade resource links SP2007 to SP2010 from Microsoft
PowerShell CMDLets for importing into SharePoint 2010
Imports Microsoft InfoPath 2010 form templates and .udcx files that are located on the SharePoint Central Administration Web site.
Updates InfoPath form templates (.xsn files) and universal data connections (.udcx files), including all .xsn files and .udcx files that were deployed by an administrator.
Runs a Microsoft InfoPath 2010 .xsn/.udc fix-up on Microsoft SharePoint Foundation 2010.
Upgrades all Microsoft InfoPath form templates on the farm.
Till the next time…
Recently I was asked to look at SharePoint 2007 install that was throwing 6641 “Logon failure: the user has not been granted the requested logon type at this computer” errors every few minutes and filling up the Application log.
We went through he normal steps of checking the service and SSP accounts, we did find that the Office Search Service had hung, but this wasn’t the problem, we checked various blogs on the web that seemed to point towards Kerberos being the problem, but this particular farm was only using NTLM. Thinking about the error “the user has not been granted the logon type at this computer”, got me thinking about logon types and failures, so a look in the Security log turned up these errors that were coinciding with the 6641’s in the Application log.
Logon type 4 is a Batch logon, the farm account was calling this but the User Name called was for a secondary SSP that we didn’t think was used. The best way to fix this would be to give the secondary SSP account the ‘Logon as a batch Job’ right via local security policy, so preserving the principle of least rights for a service account, unfortunately we couldn’t do this so a temporary measure we added the secondary SSP account to the local admins group and the 6641 errors immediately stopped.
An unfortunate side effect of the above that that we started getting the IIS WAMREG DCOM activation errors in the System event log while not a problem in itself we fixed those as well, steps outlined here for Windows 2003 / WSS 3.0 (as this system was), just make sure ALL your accounts are in the WSS_WPG group.
Once those steps were taken all 3 event logs were error free.
Anyone involved with the building / running / supporting of a SharePoint system will know how important documenting the original build configuration is.
If you build farms using the excellent AutoSPIntaller, then most of your work is already done as you have to plan things like your service accounts and database names for the inputs.xml file.
But what if you are called into look at a system that you know nothing about ?. in this case the equally excellent SPSFarmReport will come to your help.
The download zip file has versions for both WSS 3.0 / MOSS (32 & 64 bit) and SharePoint Foundation / SP2010 / Project Server 2010.
Once downloaded onto one of your servers with the binaries installed, simply run the appropriate executable under Farm account credentials, once ran you can delete the executable if needed.
The report output file is a nicely formatted HTML document that covers just about every single aspect of your farm configuration, this can be used to create your documentation guide, and as a timed snapshot of your configuration for future comparison.
Something I always forget and scramble around to find:
<xsl:template name="Debug" match="Row[@Style='Debug']" mode="itemstyle">
Property Name: <xsl:value-of select="name()"/>
Value: <xsl:value-of select="." /> <br/>
Original blog post is here:
I will be posting more stuff on the blog soon. Things are a bit manic at the moment
As per my previous post, in my current project we are starting to migrate the whole solution to live.
The project I am working on is a global solution with locations in UK, USA, India, China + others. As a result of this, like many global projects, we suffer from the available connections.
To do this, I have used the Yahoo compressor which is a java applet where you can pass in the file and output the minimised version.
Download Link: http://yuilibrary.com/downloads/#yuicompressor
How To Documentation: http://developer.yahoo.com/yui/compressor/#using
Example Command Line: java -jar yuicompressor-2.4.6.jar –nomunge –preserve-semi –disable-optimizations <input file> -o <output file>
So it has been a while since I have posted anything on the blog.
As I am sure many of you can relate, there comes a time in all projects when you have to concentrate solely on them to ensure that all factors play out as expected. One of those times would be go live time.
The project I have been working on for the last year is about to go into trial with its first division, so it has been heads down to ensure that all bug fixes and business intelligence data is correct.
As of today, we are officially at a code freeze and we are clearing down the databases to rid them of test data ready for migration to the Production environment and the final integration testing process.
As a result, we can commence blogging again, of which I have a few topics stored up.
First up is…
Project Scenario: I created a generic function to contact the User Profile service and set some default global variables when the page loads for the current logged in user.
So the basic mechanism was there already.
- I was passing the current user as a variable
- User Profile Service was already being queried
- Set the global variables for the current user
I wanted to extend this to take any user, but not upset the other functions that relied on the global variables I was setting in the function.
So essentially I added a setGlobal flag parameter and provided a default to the function so that existing code could work (surrounded by the newly created flag of course) and then implemented what I needed to.
This allowed my existing code to continue to function without issue, but also allowed me to reuse my User Profile functionalities for another purpose.
The original idea came from the following blog post:
In my code, I implemented the first method. In future however I shall certainly use the second approach.
A common thing I do for most clients is to create a unique alphanumeric ID that is consistent in length with pre-filled zeros.
Risk list alphanumeric ID example:
However, as has been documented many times (link); you cannot use the ID column of a list in a calculated column. To get over this issue I use a simple SharePoint Designer workflow to copy the ID value to another column (Unique Reference) and then base my calculation on the Unique Reference column.
Step One: Create a common site column for use across the Site Collection
- Column Name: Unique Reference
- Column Type: Single Line Of Text
Step Two: Create a calculated column for the alphanumeric ID
- Column Name: Risk ID
- Column Type: Calculated Column
- Formula: =”RSK” & TEXT([Unique Reference], “0000″)
NB: The TEXT function will prefill the ID with zeros
- Step Three: Add the Unique Reference and Risk ID column to your List or Content Type
Step Four: Create the SharePoint Designer Workflow
- Create a list or content type (SP2010 only) workflow
- Workflow should fire on Creation only (disable Manual and Edit)
- Use the following steps:
- Publish the workflow (list workflow)
- Assign the workflow to the content type (if you have created a redistributable workflow in SPD 2010) and assign the content type to the list (content type workflow)
Step Five: Hide the Unique Reference column in the list / content type
- This will stop the Unique Reference column from showing to the end user.
NB: You must hide the Unique Reference column after you have created and published the workflow otherwise it will not appear in SharePoint Designer
You list items will now have a unique alpha numeric ID
NB: Please remember that automatic workflows will not fire if you are logged in as the farm account (link)