Publish InfoPath form to different SharePoint list

Using InfoPath Designer, we cannot change the publish URL, If you want to deploy the InfoPath form from one list to another list in the same site or a different SharePoint site hence you need to update the publish URL manually by updating the manifest file of the InfoPath form.

Below are the steps to UPDATE Manifest.xsf file:

1. From the source list Open the InfoPath form using designer and go to File menu, select Save As option to save the InfoPath form. You will be saving a .xsn file.
2. You cannot use the old form as-is, because it was bound to the list by its GUID, and the new list most likely has a different GUID.
3. Rename the file from .xsn to .cab(Template.xsn to Template.cab).
4. Extract the file using Winzip to a folder.
5. Go to the extracted folder and open the file Manifest.xsf.
6. Search for your current site/list URL and replace it with the new site/list URL.
7. In addition to changing the site URL in this file, you will also need to change the GUID of each list referenced in the InfoPath form so that it matches the value in the target environment. To do that, search for all lines in manifest.xsf with "sharePointListID=" and change the GUID that follows.
8. You may also need to change the GUID value(s) for content types as well. Search through the manifest.xsf file looking for non-null values following "contentTypeID=" and change them to the GUID value in the target environment as well.

Note: To find the correct GUID of the List, ContentTypeID you will need to go to the target list --> Click on "Customize in InfoPath" from list tools, and do Save As to save the InfoPath Form. Once you save the form you can change the extension to .cab and extract the CAB file. From the extracted folder you can Open the target list Manifest.xsf file in notepad and note the GUIDs of the Lists and ContentTypeID.

If you are using Modern view then you need to navigate to List Settings--> form settings and follow the same instructions.

     9. Now we have the updated manisfest file which is pointing to the new site. Now we need to make a .XSN file out of the extracted files. You can use CabMaker tool to create the .xsn file

Download the tool from : https://github.com/sapientcoder/CabMaker/releases 

    10. Now right click on .XSN file, select design & under File menu select publish. Now you would be able to see the publish URL pointing to your new site/list.

    11. Go ahead and publish the form.

If you don't have the MakeCab tool then you can create the XSN file from the extracted folder using makecab.exe from the command prompt. Below is the content of directive file(ddf.txt)

;************************************************************ 
; MSDN Sample Source Code MakeCAB Directive file example

;************************************************************ 
.OPTION EXPLICIT 

; change the value of the caninet name for example myInfoPath.xsn
;*****************************************************************


;******************************************************************

; change the value of the Disk Directory Template value to the directory you want to store the xsn file into,,
.Set CabinetNameTemplate=NewTemplate.XSN

;**********************************************************************************************


;**********************************************************************************************

.set DiskDirectoryTemplate="C:\Users\Liakath\Documents\InfoPath"

.Set Cabinet=on
.Set Compress=on

"C:\Users\Liakath\Documents\InfoPath\Template\Audit Results5.xsd"
;*******************************************************

; Just List All the files to be added in the xsn file

;*******************************************************


"C:\Users\Liakath\Documents\InfoPath\Template\Audit Results6.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Choices Data Connection.xsd"
"C:\Users\Liakath\Documents\InfoPath\Template\Audit Results7.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Audit Results8.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Audit Results9.xsd"


"C:\Users\Liakath\Documents\InfoPath\Template\choices.xml"

"C:\Users\Liakath\Documents\InfoPath\Template\Close.xsl"

"C:\Users\Liakath\Documents\InfoPath\Template\EmpInfo10.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\EmpInfo11.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\EmpInfo12.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\EmpInfo13.xsd"
"C:\Users\Liakath\Documents\InfoPath\Template\EmpInfo9.xsd"
"C:\Users\Liakath\Documents\InfoPath\Template\EmpInfo14.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\EmpInfo15.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\EmpInfo6.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\EmpInfo7.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\EmpInfo8.xsd"


"C:\Users\Liakath\Documents\InfoPath\Template\FormTypeSelection.xsl"
"C:\Users\Liakath\Documents\InfoPath\Template\ExpenseCodes5.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\ExpenseCodes6.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\ExpenseCodes7.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\ExpenseCodes8.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\ExpenseCodes9.xsd"


"C:\Users\Liakath\Documents\InfoPath\Template\LiabRequestTypeAdmin.xsd"
"C:\Users\Liakath\Documents\InfoPath\Template\GetUserProfileByName1.xml"

"C:\Users\Liakath\Documents\InfoPath\Template\GetUserProfileByName3.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\GetUserProfileByName4.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\GetUserProfileByName5.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Liability.xsl"


"C:\Users\Liakath\Documents\InfoPath\Template\LiabRequestTypes1.xsd"
"C:\Users\Liakath\Documents\InfoPath\Template\LiabRequestTypeAdmin1.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\LiabRequestTypeAdmin2.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\LiabRequestTypeAdmin3.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\LiabRequestTypeAdmin4.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\LiabRequestTypes.xsd"


"C:\Users\Liakath\Documents\InfoPath\Template\Office Number Translation7.xsd"
"C:\Users\Liakath\Documents\InfoPath\Template\LiabRequestTypes2.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\LiabRequestTypes3.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\LiabRequestTypes4.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\manifest.xsf"

"C:\Users\Liakath\Documents\InfoPath\Template\Office Number Translation5.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Office Number Translation6.xsd"


"C:\Users\Liakath\Documents\InfoPath\Template\PropRequestTypes3.xsd"
"C:\Users\Liakath\Documents\InfoPath\Template\Office Number Translation8.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Office Number Translation9.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Property.xsl"

"C:\Users\Liakath\Documents\InfoPath\Template\PropRequestTypes.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\PropRequestTypes1.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\PropRequestTypes2.xsd"


"C:\Users\Liakath\Documents\InfoPath\Template\PropRequestTypes4.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\schema.xsd"
"C:\Users\Liakath\Documents\InfoPath\Template\PropRequestTypesAdmin5.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\PropRequestTypesAdmin6.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\PropRequestTypesAdmin7.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\PropRequestTypesAdmin8.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\PropRequestTypesAdmin9.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\sampledata.xml"

"C:\Users\Liakath\Documents\InfoPath\Template\Save.xsl"


"C:\Users\Liakath\Documents\InfoPath\Template\schema1.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Suspended Reason6.xsd"
"C:\Users\Liakath\Documents\InfoPath\Template\schema2.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\schema3.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\schema4.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Status.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Status1.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Status2.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Status3.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Status4.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Suspended Reason5.xsd"


"C:\Users\Liakath\Documents\InfoPath\Template\WCRequestTypes9.xsd"
"C:\Users\Liakath\Documents\InfoPath\Template\Suspended Reason7.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Suspended Reason8.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\Suspended Reason9.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\template.xml"

"C:\Users\Liakath\Documents\InfoPath\Template\upgrade.xsl"

"C:\Users\Liakath\Documents\InfoPath\Template\WCRequestTypes5.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\WCRequestTypes6.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\WCRequestTypes7.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\WCRequestTypes8.xsd"


;*********************
"C:\Users\Liakath\Documents\InfoPath\Template\WCRequestTypesAdmin10.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\WCRequestTypesAdmin6.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\WCRequestTypesAdmin7.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\WCRequestTypesAdmin8.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\WCRequestTypesAdmin9.xsd"

"C:\Users\Liakath\Documents\InfoPath\Template\WorkComp.xsl"

;*********************

; End of the File

After SharePoint CU upgrade, WSP package failing to deploy in some servers

Issue Description:This issue started happening after the Sep 2017 CU upgrade and that this issue is happening only one server where the solution is not getting deployed. The other server gets the solution deployed correctly.

1. We started seeing this issue after patching. This is a common behavior we see in SharePoint On prem environments where the Logical SharePoint Timer Service instance goes into Offline/Disabled mode on one or more servers. Ideally after the PSConfig is completed successfully, it should move the Timer service instance back in Online state, however, in some instances, when there are some issues with PSConfig during one of the steps, it fails to get all the Timer service instances back online. This makes the timer jobs on the server ( where the Timer Service instance didn’t come back online) not processing correctly. 
• This issues doesn’t come up to the surface in obvious way because the OWSTIMER.exe ( SharePoint Timer service) in Windows Services.msc console would remain running, so it would not throw any errors in Application Event logs or in ULS logs. However, since the logical Timer service instance is Offline on the server, the timer jobs would not be processed. This applies to all the timer jobs and not specific to WSP related timer jobs.
2. Continuing from above point, I don’t believe the issue is with the WSP solution as we were able to deploy it successfully right after getting the Offline Timer Service instance back Online.

Review:

• As per the logs, found the Timer job to be created for solution deployment but not actually getting through with deployment.

02/20/2018 10:23:10.54                 PowerShell.exe (0x0A2C)             0x0A5C SharePoint Foundation  PowerShell         6tf0       
Medium               Entering ProcessRecord Method of install-spsolution.     9a36ccdf-5135-4057-b3a7-90a009e136f4

02/20/2018 10:23:10.88                 PowerShell.exe (0x0A2C)             0x0A5C SharePoint Foundation  Topology             8uav     
 Verbose               Solution Deployment : Created timer job for branding.wsp, id : 8b0ebc5b-c659-4105-8e7a-cf62a3458360               9a36ccdf-5135-4057-b3a7-90a009e136f4

02/20/2018 10:23:10.88                 PowerShell.exe (0x0A2C)             0x0A5C SharePoint Foundation  Topology             8ucn     
Verbose               Solution Deployment : Deleting OperationStatus object for solution branding.wsp          
 9a36ccdf-5135-4057-b3a7-90a009e136f4

02/20/2018 10:23:10.88                 PowerShell.exe (0x0A2C)             0x0A5C SharePoint Foundation  PowerShell         6tf0       
Medium               Leaving ProcessRecord Method of install-spsolution.       9a36ccdf-5135-4057-b3a7-90a009e136f4

Explanation:

• Each SharePoint server has Physical Timer Service ( OWSTIMER.exe) which is a Windows level service ( which is responsible for processing all the timer jobs), however, each SharePoint server also has Logical SharePoint Timer Service instance ( this is the piece which resides in SharePoint code base).
• We require the Logical Timer service instances to be Online on all servers for SharePoint to be able to process the Timer jobs.
• We ran the following script to identify if all the Timer service instances were Online on all servers and found that the affected server’s Timer Service Instance was set to Disabled.

$farm  = Get-SPFarm
$disabledTimers = $farm.TimerService.Instances | where {$_.Status -ne "Online"}
if ($disabledTimers -ne $null)
{
    foreach ($timer in $disabledTimers)
    {
        Write-Host "Timer service instance on server " $timer.Server.Name " is not Online. Current status:" $timer.Status
        Write-Host "Attempting to set the status of the service instance to online"
        $timer.Status = [Microsoft.SharePoint.Administration.SPObjectStatus]::Online
        $timer.Update()
    }
}
else
{
    Write-Host "All Timer Service Instances in the farm are online! No problems found"
}

• We enabled the Timer service instance via above script and after that we tried to deploy the solution again via Central Admin site and it was successful on both servers.

Important Note:

• When the Timer Service instance is not enabled on any of the server, you would see all timer jobs on that server getting impacted. You won’t see any errors in the ULS logs, however, above script would be a good way to check if all Timer service instances are online in the farm.

Reference:

https://blogs.msdn.microsoft.com/tehnoonr/2011/09/07/sharepoint-server-2010-timer-jobs-not-functioning-after-applying-updates/

 Add this step to patching activity: 

As an additional safeguard method, I would recommend to add following step in your Patching process so that we can explicitly make sure that all Timer service instances in the farm are Online after the Patching process is completed. You can add this step as part of your Patching process documentation and this will avoid any issues with Timer service instance.

Run following script from one of the SharePoint server after the Patching process is complete. This will check for any Offline/Disabled Timer Service instances and Enable them.

Update the "Created By" "Modified By" and "Created" Columns in ShrePoint list using PowerShell

As a developer or administrator working with SharePoint, sometimes it is necessary to modify the 'Created' 'Created By' 'Modified' 'Modified By' columns where we can not modify in UI.

But using PowerShell easily you can modify these columns.

// Add only if you use windows PowerShell. 
Add-PSSnapin Microsoft.SharePoint.Powershell 

//Get a new object called $web to pick site 
$web=Get-SPWeb "URL" 

//Get a new object called $list to pick list
$list=$web.Lists["List Name"] 

Now you need to get the particular List Item ID, where you want to modify the columns.

//Get a new object called $item to pick Item
$item = $list.GetItemById("3214")

Now you need to get the columns names which you want to update. You can get the user ID of the user using the "EnsureUser()" method of "web" in PowerShell command.

$replacedUser =$web.EnsureUser("domainName\Account")

Note: The Author and Editor fields, these are the 'Created by' and 'Modified by' fields.
Author = Created by
Editor = Modified by

// Add only if you use windows PowerShell. 
Add-PSSnapin Microsoft.SharePoint.Powershell 
//Get a new object called $web to pick site 
$web=Get-SPWeb "URL" 
//Get a new object called $list to pick list
$list=$web.Lists["List Name"]
//Get a new object called $item to pick Item
$item = $list.GetItemById(3214)
$replacedUser =$web.EnsureUser("domainName\Account")
$item["Created"] = "25/2/2013 00:00:00"
$item["Modified"] = "25/8/2013 00:00:00"
$item["Author"] = $replacedUser
$item["Editor"] = $replacedUser
$item.Update();

Custom Sharepoint timer jobs are not displaying in the Central Administration

Recently i have an issue in our Custom Timer jobs. So we fixed that issue and tried to start timer job manually for testing. But in Central Admin--> Monitoring--> Job Definitions  here i could not see the custom timer jobs.
But in back end timer jobs are running and i could see the updates in SharePoint lists.

Reason:
When you deploy the WSP solution using STSADM or POWERSHELL it will be deployed only to those servers which have WFE role. Application servers may not have WFE role. So if your app server is not WFE, custom assemblies won’t be installed to its GAC.

For workaround you can follow the below methods.
 

Method 1: Using powershell script deactivate the features and again enabled it. Now you could see the timer jobs in Job History not in Job definitions. Previously even the jobs not appearing in job history also.
 

See method 2, if you want to display the custom timer jobs in job definitions to start manually.
 

Method -2: Application servers should have the timer job dlls in the assembly. For this add the dll's to GAC.

1. Manually if you try to add the dll's to GAC you will see the access denied error. To fix this please see this Manually how to install an Assembly into the GAC without gacutil

Once you add the dll's to application server gac perform iisreset. Now can see the custom timer jobs in central admin farm.

NOTE: These dlls won't be updated next time you upgrade the solution. Because solutions are not upgraded automatically on the server without WFE role. Again manually you will need to add the dlls to application server GAC.

In SharePoint 2010 environment based on the active services, will decide what is the application servers and what is the wfe's. WFE's will have the service 'SharePoint Foundation Application' in turn on mode. 

In Application server this service will be inactive mode .

So you will need to activate the same service in Application server also. So the application server will have the WFE role. Then you can see the custom timer jobs in central admin farm.

For detailed explanation see this link

Manually how to install an Assembly into the GAC without gacutil

In Production (APP/WFE) server we may not have Visual Studio installed in, and we don't have gacutil.exe. In worst cases manually if you need to add the dll's to GAC for workaround you can follow the below steps.

1. Start--> Local Security Policy --> Local Policies --> Security Options --> and right click on the 'User Account Control: Run all administrators in Admin Approval Mode' and disabled it.

You should restart the Server to turn off the UAC Admin mode.

2. Add the dll's to (drag and drop) assembly(C:\windows\assembly\)

3. Once you add the dlls to gac again enable the UAC admin mode and restart the server.

'Value was either too large or too small for an Int16' in SharePoint 2010 Task Edit Form

Received the below custom error, while trying to approve the task from Task Edit Form page.

In our application, suddenly we received this custom error. Before that, application working fine and approvers are able to open the form and able to Approve/Reject the task.

In the highlighted code statement, a 32-bit integer is attempted to be converted to 16-bit integer, whereas the variable is of type 32-bit int. This breaks the rendition of custom task edit form, logs a warning in ULS and redirect to error page.

Error logged in ULS (attached):

Message: Value was either too large or too small for an Int16.

StackTrace:   

                at System.Convert.ToInt16(Int32 value)    

                at System.Convert.ToInt16(Object value)    

                at Project.SP.Pages.Layouts.TaskEditForm.GetTaskListInformation()

                at Project.SP.Pages.Layouts.TaskEditForm.Page_Load(Object sender, EventArgs e)

Int16 variables can hold the values from 0 to 32767.

But The task that fails on custom edit form has associated workflow id 33248.

Workflow instances are assigned IDs incrementally (may not be necessarily be sequentially). It must have exceeded 32767 recently, hence the custom form with that code blow out loading the page.

Code snippet:

//Get the parent List item Id

   this.parentListItemId = Convert.ToInt16(this.taskListItem[SPBuiltInFieldId.WorkflowItemId]);

Code fix:

//Get the parent List item Id

  this.parentListItemId = Convert.ToInt32(this.taskListItem[SPBuiltInFieldId.WorkflowItemId]);

Int32 variables can hold max values is : 2,147,483,647