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

"The form cannot be submitted because of an error" in Approval Workflow

Using with Approval Workflow template i have created a workflow at Pages Library.
The problem i am having is when i add user to reviewer and CC people picker control and click on start to start the workflow it's showing me "The form cannot be submitted because of an error" error.

Initially all things were working and i was able to submit the workflow with Approvers and CC.

Solution 1:
Uninstall the update Security update for Info path 2010 (KB2553322) either 32 or 64bit for SharePoint Designer.
In my environment at control panel i didn't see this update.

Solution 2:

To verify the problem in SharePoint Designer, Site --> All Files --> _catalog --> wfpub --> Workflow Name (In my case 'Approval Workflow'). Open Approvalworkflow.xoml.wfconfig.xml and click on edit.
Here Search with xsi:nil="true" in XML code and check at WofkflowConfig --> Intitiation --> DefaultData --> dfs:myFields ---> dfs:dataFields --> <d:SharePointListItem_RW>
In my case i observed xsi:nil="true" at Assignee and CC. So Delete xsi:nil="true" in the Approvers and CC feilds 

<d:Approvers >
        <d:Assignment >
            <d:Assignee/>
            <d:Stage xsi:nil="true"/>
            <d:AssignmentType>Serial</d:AssignmentType>
        </d:Assignment >
    </d:Approvers xsi:nil="true"> <!-- instead it must be </d:Approvers> -->
    <d:ExpandGroups>true</d:ExpandGroups>
    <d:NotificationMessage/>
    <d:DueDateforAllTasks xsi:nil="true"/>
    <d:DurationforSerialTasks xsi:nil="true"/>
    <d:DurationUnits>Day</d:DurationUnits>
    <d:CC xsi:nil="true"/>        <!-- instead it must be <d:CC/> -->
    <d:CancelonRejection>false</d:CancelonRejection>
    <d:CancelonChange>false</d:CancelonChange>
    <d:EnableContentApproval>false</d:EnableContentApproval>

 Save and publish the workflow again. Now you will not see the error message.

SharePoint 2010 - How to Configure an Alternate Access Mapping

This is quick reference for how to give alternate access mapping to SharePoint site through central administration.

• Alternate Access Mappings (AAM) is a feature of SharePoint that allows you to access your SharePoint site with another URL.
• AAM will help you Without exposing the server name or port numbers. and it is common request in SharePoint administration is to add another URL to an existing site.

There are 3steps we need to do:

1. Create a binging for the SharePoint site in IIS
2. Create AAM in SharePoint Central Administration
3. Add your domain in DNS entries and point the IP address to the SharePoint Server.

1. Create a binding for the SharePoint site in IIS:

    Edit the site bindings

            Start IIS manager -->Right-click the site and "edit bindings" or go for Actions in right panel then click on Bindings. --> Give your URL in In 'Host'.

2. Create AAM in SharePoint Central Administration

We had finished for IIS manager. Now we need to give the access from SharePoint too. Ensure that you should be a member of the Farm Administrators SharePoint group, to operate the Central Administration site. 

• From Central Admin -->Application Management-->click on Configure alternate access mappings under Web Applications.
• Edit the alternate access mapping
• Choose the correct "alternate access mapping collection" at the top right Choose "Edit Public URLs" Add the new URL for the zone which you want. (ex: Internet)

3. Add your domain in DNS entries and point the IP address to the SharePoint Server

    Now you’ll have to switch over to your DNS server.

1. Within the DNS Management Console : Add a new Primary Zone with your new domain name.       
2. Add a new Host to the records and point the IP Address to the SharePoint server.

Now you can have Alternate URLs pointing to your SharePoint Site Collection or whatever you’d like.