Sharepoint 2010 is here with powershell integration making it easy to change the passwords for sharepoint managed accounts whose passwords are not set to change automatically when nearing expiration. 

1) Change the password in AD for service account.

2) Update the password for the service accounts in the sharepoint 2010 farm .

Here is a quick run through

Change the password in AD for service account.

I assume  you can log on to a windows 2008 r2 server in domain where service account exists , you have rights to change the password for the service account. I am using a fictitious account  by the name _svc_acct for this scenario

a) After logging into a server in account domain  launch powershell

b ) Load the AD module

import-module activedirectory

c) Assign the account name to a variable

     $account="_svc_acct"

d) set the password ( please note this as we will be using this in the next section)

     Set-ADAccountPassword -Identity $account -OldPassword (ConvertTo-SecureString -AsPlainText  "xxxx" -Force) -NewPassword (ConvertTo-SecureString -AsPlainText "xxxxx" -Force)

e) Check for successful update of the password updation  ( out put should show recent tiem stamp)

Get-ADUser $account -properties * | select PasswordLastSet

For engineers who do not have windows 2008 r2 machines , you can always change password through your normal process.

Update the password for the service accounts in the sharepoint 2010 farm .

 a) Log on to the CA in the Farm, launch powershell.  Assign the new password from step d in the above section to a variable also store the account to a variable

$account="_svc_acct"

$securepassword=convertto-securestring "xxxxx" -asplaintext -force

b) Retrieve the Sp managed account   and pipeline it to the set-spmangedaccount cmdlet

Get-SPManagedAccount Domain\$account | Set-SPManagedAccount -ExistingPassword $securepassword -UseExistingPassword -confirm:$false

The entire Detail section of a Microsoft Access form goes blank sometimes. The text boxes you see in design view disappear when you go to use the form, leaving nothing but empty space.

The Cause

It happens when both these conditions are met:

1. There are no records to display, and
2. No new records can be added.

Condition (a) can be triggered in several ways. Examples:

• The form's Data Entry property is set to Yes. (This means the form shows no existing records, i.e. it is for entering new ones only.)
• The form has a Filter applied (or is opened with a WhereCondition) that yields no records.
• The form is based on a query where the criteria yield no records.
• The form is based on a table that has no records.

Condition (b) can be also be triggered by several things:

• The form's Allow Additions property is set to No.
• The form's Recordset Type property is set to something other than Dynaset.
• The form is based on a read-only query. (If you cannot add a record directly to your query)

You can demonstrate the problem with any form, just by setting its Data Entry property to Yes, and Allow Additions to No.

If it has Form Header and Form Footer sections, controls in these sections will still be visible but they may not work properly.

Workarounds

You cannot prevent this from happening, unless you can avoid (a) and (b) being true at the same time.

If you have set Allow Additions to No so as to prevent new records, there is a simple workaround. Set Allow Additions back to Yes, so the form can show the new record when there are no others. You can prevent new records by canceling the BeforeInsert event of the form. Steps:

1. Set the Before Insert property of the form to:    [Event Procedure]
2. Click the Build button (...) beside this. Access opens the code window.
3. Insert the line Cancel = True between the other two. The code will look like this:
       Private Sub Form_BeforeInsert(Cancel As Integer)
           Cancel = True
       End Sub

If you cannot prevent condition (b), you might be able to prevent condition (a). For example, if you are opening a form with a WhereCondition that could result in no records, you might prefer to display a dialog rather than the blank form. To do that, cancel the Open event of the form:

Private Sub Form_Open(Cancel As Integer)
    If Me.RecordsetClone.RecordCount = 0 Then
        Cancel = True
        MsgBox "No records"
    End If
End Sub

(Note: The procedure where you used OpenForm will be notified with error 2501 that the form did not open. Use error handling in that procedure to trap the message.)

There are times when you cannot prevent (a) and (b) happening together. A complex search form may have to use a read-only query, and the user's criteria may return no results. For these cases, place the criteria boxes in the form header section, and accept the fact that users will be okay if they see nothing when the search returns no results.

January 2010 update: In Access 2007 and later, check that the form's Filter On Load property is set to No so that it does not automatically apply a previously saved filter when you open  the form.

Problem: Customer discovered that the ULS logs had stopped generating. Within the Logs file there were files but from an old date.

Troubleshooting: I looked in Event viewer and found this:

Tracing Service failed to create the trace log file at location specified in SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0\LogDir Error 0x0: The operation completed successfully. . Traces will be written to the following directory: C:\Windows\SERVIC~2\LOCALS~1\AppData\Local\Temp\.

Resolution:

1. In Central Admin go to Monitoring>>Configure diagnostic logging
2. changed the ‘Path’ value to C:\Temp and then back to D:\SharePoint\Logs or %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\14\LOGS\, or whatever it was before! (changing it back and forth resolved this problem) 

The Event Log should stop reporting this error!

Had an issue with Audiences in Sharepoint 2010, Kept getting the error “There were problems searching audience, please contact the system administrator.” whenever I tried to add/target an audience in my Sharepoint 2010 in the Top Navigation.

What this error normally/really means is that Sharepoint cannot connect to the User Profile Service Application Proxy (You would get a similar error if your Enterprise search was trying to crawl your user profiles) or the User Profile Synchronization Serive (UPSS), which was my case.

To fix this you need to

1. Open “Central Administration”
2. Click “Application Management”
3. Click “Manage Web Applications”
4. Find and click on the “Web Application” or “Website” you are getting the error in (in my case ‘sharepoint -80′)
5. Click “Service Connections” under the “Manage” ribbon
6. Make sure that “User Profile Service Application” is checked (you may have to change from default to custom to be able to do this). This MIGHT be unchecked if you have recently deleted the default User Profile Service Application and created a new one using a different name, like I did, AND the Connection is NOT set to Default!!

Original Post: http://technet.microsoft.com/en-us/library/gg251984(v=office.14).aspx

Convert SharePoint Foundation 2010 Web applications that use classic-mode authentication to use claims-based authentication

Perform the steps in the following procedure to use Windows PowerShell to convert existing Web applications to claims-based authentication.

To convert Web applications to claims-based authentication

1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

2. On the Start menu, click All Programs.

3. Click Microsoft SharePoint 2010 Products.

4. Click SharePoint 2010 Management Shell.

5. From the Windows PowerShell command prompt, type the following:

   Copy

   $WebAppName = "http:// yourWebAppUrl"
   $account = "yourDomain\yourUser"
   $wa = get-SPWebApplication $WebAppName
   
   Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default
   
   

6. At the Migration prompt, click Yes to continue.

7. From the Windows PowerShell command prompt, type the following to set the user as an administrator for the site:

   Copy

   $account = "yourDomain\yourUser"
   $account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()
   $zp = $wa.ZonePolicies("Default")
   $p = $zp.Add($account,"PSPolicy")
   $fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
   $p.PolicyRoleBindings.Add($fc)
   $wa.Update()
   
   

8. From the Windows PowerShell command prompt, type the following to configure the policy to enable the user to have full access:

   Copy

   $zp = $wa.ZonePolicies("Default")
   $p = $zp.Add($account,"PSPolicy")
   $fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
   $p.PolicyRoleBindings.Add($fc)
   $wa.Update()
   

9. From the Windows PowerShell command prompt, type the following to perform user migration:

   Copy

   $wa = get-SPWebApplication $WebAppName
   $wa.MigrateUsers($true)
   

Note:
We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

 

Additional migration guidelines

Original Link: http://techtrainingnotes.blogspot.ca/2012/01/sharepoint-move-add-new-link-to-top-of.html

So you want to "MOVE" that Add Item/Add Document Link to the top of the View because your customer is so annoyed that they have to scroll to the bottom all the time. Mike has written a brilliant script that does this for you! Now my customer is happy again.

Hey, also check out Mike's Book at Amazon.

Hope this helps some else out there like it helped me!
Dave

Exporting and importing of the List Workflow to and from another list or site is actually a non-supported feature. However, there is a "workaround" to achieve this.

1. In SharePoint Designer 2010, click on your completed List Workflow.
2. Click on "Save" and "Publish" for the completed List Workflow.
3. Next, click on "Export to Visio". Save the file as CompletedWorkflow.vwi or any preferred name.
4. Then create a new "similar" list on the current site or on a new site collection. There is no way to import the exported visio into this new list.
5. In SharePoint Designer 2010, click on this new list and then click on "List Workflow" to create a new workflow for this new list.
6. Please make sure that you do not add any workflow steps!
7. Click on "Save" and "Publish" for this empty List Workflow.
8. Then, click on "Export to Visio" and save this as EmptyWorkflow.vwi or any preferred name.
9. Rename both the vwi files by adding ".zip" extension. The files should be CompletedWorkflow.vwi.zip and EmptyWorkflow.vwi.zip.
10. The objective is to replace the "workflow.xoml.wfconfig.xml" file from the EmptyWorkflow.vwi.zip into the CompletedWorkflow.vwi.zip.
11. It is likely that you cannot replace it directly. Copy the file out to the desktop and then copy the file into the other zipped folder.
12. Remove the ".zip" extension from the CompletedWorkflow.vwi.
13. With this, we have a working importable visio List Workflow.
14. Back in the SharePoint Designer 2010, close all the workflow tabs.
15. Click on the "Import from Visio" and select the CompletedWorkflow.vwi.
16. You have successfully exported and imported the List Workflow!

Original Post: http://blogs.msdn.com/b/rds/archive/2009/08/11/introducing-web-single-sign-on-for-remoteapp-and-desktop-connections.aspx

In Windows Server 2008 R2, the Web Single Sign-On (Web SSO) feature provides users with the ability to enter their credentials only once during logon to Remote Desktop Web Access (RD Web Access). After logon, users can launch RemoteApp programs that are part of the same connection in RemoteApp and Desktop Connections without any further credential prompts, even if the RemoteApp programs are configured to use RD Gateway.

This post describes how to configure RD Session Host and RD Connection Broker servers to take advantage of the Web SSO feature when launching RemoteApp programs from RD Web Access.

Why is Web SSO necessary?

In Windows Server 2008 TS Web Access, a major pain point for users was receiving multiple credential prompts, first when logging on to TS Web Access and then when launching a RemoteApp program from a terminal server.

In Windows Server 2008 R2, using the new RD Web Access Forms Based Authentication (FBA), users will now have to enter credentials only once in the login page of RD Web Access and will not be prompted again for entering credentials on launching subsequent apps from the RemoteApp Programs page of RD Web Access.

How it works

RD Web Access can access RemoteApp programs in two modes (details about these modes can be found in this post):

• RD Session Host mode for small to medium deployments
• RD Connection Broker mode for large deployments

What is supported

Web SSO is supported for launching RemoteApp programs from RD Web Access or the Start menu in any of the above modes. For Web SSO to work when connecting to personal desktops or pooled virtual machines (VMs) the client machine needs this hotfix installed:  http://support.microsoft.com/kb/2524668.

Requirements

• To take advantage of the new Web SSO feature, the client must be running Remote Desktop Connection (RDC) 7.0.
• In order for Web SSO to work:

1.  
   1. The connection in RemoteApp and Desktop Connections must have an ID. By default, it is set to the Fully Qualified Domain Name (FQDN) of the RD Connection Broker server in case of RD Connection Broker mode. In RD Session mode, it is set to the FQDN of the RD Web Access server.
   2. RemoteApp programs must be digitally signed using a Server Authentication certificate [Secure Sockets Layer (SSL) certificate]. The certificate Enhanced Key Usage section must contain ‘Server Authentication (1.3.6.1.5.5.7.3.1)’. More details about the types of certificates used to digitally sign RemoteApp programs can be found here.
   3. Client operating systems must trust the certificate with which the RemoteApp programs are signed.

The steps for configuring Web SSO and setting up a digital signature for RemoteApp programs for RD Session Host and RD Connection Broker modes are described below.

Configuring Web SSO when using RD Session Host mode

There are 2 steps required to configure Web SSO when using RD Session Host.

• Step 1: Add the RD Web Access server to the TS Web Access Computers group on the RD Session Host server
• Step 2: Digitally sign the RemoteApp programs on the RD Session Host server

Membership in the local Administrators group (or equivalent) on the RD Session Host server that you plan to configure is the minimum requirement to complete each of the following steps.

Step 1: Add the RD Web Access server to the TS Web Access Computers group on the RD Session Host server

1. On the RD Session Host server, click Start, point to Administrative Tools, and then click Computer Management.
2. In the left pane, expand Local Users and Groups, and then click Groups.
3. In the right pane, double-click TS Web Access Computers.
4. In the TS Web Access Computers Properties dialog box, click Add.
5. In the Select Users, Computers, Service Accounts, or Groups dialog box, click Object Types.
6. In the Object Types dialog box, select the Computers check box, and then click OK.
7. In the Enter the object names to select box, specify the computer accounts of the RD Web Access server and the RD Connection Broker server, and then click OK.
8. Click OK to close the TS Web Access Computers Properties dialog box.

Step 2: Digitally sign the RemoteApp programs on the RD Session Host server

1. On the RD Session Host server, open RemoteApp Manager. To open RemoteApp Manager, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click RemoteApp Manager.
2. In the Actions pane of RemoteApp Manager, click Digital Signature Settings. (Or, in the Overview pane, next to Digital Signature Settings, click Change.)
3. Select the Sign with a digital certificate check box.
4. In the Digital certificate details box, click Change.
5. In the Select Certificate dialog box, select the certificate that you want to use, and then click OK.
   
   Note: The Select Certificate dialog box is populated by certificates that are located in the local computer's certificates store or in your personal certificate store. The certificate that you want to use must be located in one of these stores.

Configuring Web SSO when using RD Connection Broker mode

There are 5 steps required to configure Web SSO when using RD Connection Broker.

• Step 1: Add the RD Web Access server to the TS Web Access Computers group on the RD Connection Broker server
• Step 2: Add RD Session Host servers as RemoteApp Sources on RD Connection Broker server
• Step 3: Add the RD Connection Broker server to TS Web Access Computers group on each RD Session Host server
• Step 4: Digitally sign the RemoteApp programs on each RD Session Host server
• Step 5: Specify certificate on RD Connection Broker server
  Note: The certificate for digitally signing RemoteApp programs on each RD Session Host server and RD Connection Broker server should be the same.

Membership in the local Administrators group, or equivalent, on the specific server that you plan to configure is the minimum required to complete each of the following steps.

Step 1: Add the RD Web Access server to the TS Web Access Computers group on the RD Connection Broker server

1. On the RD Connection Broker server, click Start, point to Administrative Tools, and then click Computer Management.
2. In the left pane, expand Local Users and Groups, and then click Groups.
3. In the right pane, double-click TS Web Access Computers.
4. In the TS Web Access Computers Properties dialog box, click Add.
5. In the Select Users, Computers, Service Accounts, or Groups dialog box, click Object Types.
6. In the Object Types dialog box, select the Computers check box, and then click OK.
7. In the Enter the object names to select box, specify the computer accounts of the RD Web Access server and the RD Connection Broker server, and then click OK.
8. Click OK to close the TS Web Access Computers Properties dialog box.

Step 2: Add RD Session Host servers as RemoteApp Sources on RD Connection Broker server

1. On the RD Connection Broker server, open Remote Desktop Connection Manager. To open Remote Desktop Connection Manager, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click Remote Desktop Connection Manager.
2. In the left pane, click RemoteApp Sources, and then on the Action menu, click Add RemoteApp Source.
3. In the Add RemoteApp Source dialog box, in the RemoteApp source name box, enter the name of the RD Session Host server or the DNS name of the RD Session Host server farm that is hosting the RemoteApp programs, and then click Add.
   Note: Do not enter the name of each RD Session Host server in the RD Session Host server farm. If you do, users will see multiple instances of the RemoteApp program icons.
4. The RemoteApp source name will appear in the center pane. To add additional RemoteApp sources, repeat the previous steps.

Step 3: Add the RD Connection Broker server to TS Web Access Computers group on each RD Session Host server

1. On the RD Session Host server, click Start, point to Administrative Tools, and then click Computer Management.
2. In the left pane, expand Local Users and Groups, and then click Groups.
3. In the right pane, double-click TS Web Access Computers.
4. In the TS Web Access Computers Properties dialog box, click Add.
5. In the Select Users, Computers, or Groups dialog box, click Object Types.
6. In the Object Types dialog box, select the Computers check box, and then click OK.
7. In the Enter the object names to select box, specify the computer account of the RD Connection Broker server, and then click OK.
8. Click OK to close the TS Web Access Computers Properties dialog box.

Step 4: Digitally sign RemoteApp programs on each RD Session Host server

Use the following steps to sign RemoteApp programs by using RemoteApp Manager. The procedure assumes that you are working from a central administrator workstation, the certificate is stored on the central administrator workstation, and the central administrator workstation has the RemoteApp Manager tool installed.

1. On the central administrator workstation, open RemoteApp Manager. To open RemoteApp Manager, click Start, click Administrative Tools, click Remote Desktop Services, and then click RemoteApp Manager.
2. On the Action menu, click Connect to Computer.
3. Select Another Computer, enter the fully qualified domain name (FQDN) of the RD Session Host server, and then click OK.
4. On the Action menu, click Digital Signature Settings.
5. Select the Sign with a digital certificate check box.
6. Click Change, select the certificate to be used for signing, and then click Apply.
7. Click OK to close the RemoteApp Deployment Settings dialog box.

Repeat the steps in the procedure for each RD Session Host that is providing RemoteApp programs through RemoteApp and Desktop Connection.

Step 5: Specify certificate on RD Connection Broker server

1. On the RD Connection Broker server, open Remote Desktop Connection Manager. To open Remote Desktop Connection Manager, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click Remote Desktop Connection Manager.
2. Select the root ‘Remote Desktop Connection Manager: <RD Connection Broker Machine Name> ’
3. In the middle pane, in the Status area, click on Specify beside the Digital certificate (shown below).
   
   
4. Follow ‘Step 2: Digitally sign RemoteApp programs on RD Session Host server’ in the ‘Configuring Web SSO when using RD Session Host mode’ section above.

Configuring the client computer for Web SSO

If the RemoteApp programs are signed using a certificate from a public CA that participates in the Microsoft Root Certificate Program Members program (http://go.microsoft.com/fwlink/?LinkID=59547), then Web SSO should just work.

If the certificate is not issued by a trusted public CA, the certificate must be imported into the Trusted Root Certification Authorities certification store on the client computer to be trusted by the client operating system. Members of the local Administrators group, or equivalent, on the client computer can import the certificate or it can be done by using Group Policy.

The ‘Trusted Certificate Authority Root’ certificate (shown below) must be imported in the Trusted Root Certification Authorities certification store on the client computer and on the RD Session Host and RD Connection Broker machines. ‘Certificate for Signing Remote App Programs’ certificate must be imported in the Personal store on the RD Session Host, and RD Connection Broker machines.

Web SSO in Windows Integrated Authentication

If RD Web Access is configured to use Windows Authentication, which is the Windows Server 2008 mode, instead of the default Forms Based Authentication (FBA), users will be prompted for credentials twice: once for the Windows Integrated Authentication for RD Web Access and again on the launch of the first RemoteApp in the RemoteApp and Desktop Connection. Thereafter on subsequent RemoteApp launch, SSO will work as it works in the FBA mode.

Web SSO with RD Gateway

Web SSO also works when RemoteApp programs are set to use RD Gateway regardless of whether RD Web Access accesses RemoteApp programs in RD Session Host mode or RD Connection Broker mode.

The configuration of Web SSO for RD Gateway assumes that:

• an RD Gateway is deployed
• a ‘Connection Authorization Policy’ is set to use password for the users connecting
• and the RD Gateway server is used by RemoteApp programs

More details on how to configure a ‘Connection Authorization Policy’ on RD Gateway can be found here.

The step below is needed regardless of the mode RD Web Access is configured. In case of RD Connection Broker mode, the step needs to be performed on each RD Session Host server which is added as a RemoteApp Source on RD Connection Broker Server.

Membership in the local Administrators group (or equivalent) on the RD Session Host server that you plan to configure is the minimum requirement to complete each of the following steps.

1. On the RD Session Host server, open RemoteApp Manager. To open RemoteApp Manager, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click RemoteApp Manager.
2. In the Actions pane of RemoteApp Manager, click RD Gateway Settings. (Or, in the Overview pane, next to RD Gateway Settings, click Change.)
3. Select the Use these RD Gateway server settings.
4. In the Server name box, click the FQDN of the RD Gateway server.
5. In the Logon box, select the Ask for password (NTLM).
6. Select the Use the same user credentials for RD Gateway and RD Session Host server check box.
7. Click OK to close the RemoteApp Deployment Settings dialog box.

So you have RemoteApp up and running and you have made an MS Access database available in the list of Remote Apps, but when you open it you get a message stating that the Database is read-only and that you can only update Linked tables!

Most likely this is a permissions error. Make sure that the RemoteDesktop Users group, whatever that is named on your server, has full permissions on the Folder housing your database, and on the database file itself.

Hope this helps someone!

In order to update the list we can either use SPListItem.update or SPLIstItem.SystemUpdate or UpdateOverwrite version
The basic difference between these three methods is as follows

SystemUpdate()
• Update the database with the fields you want to change
• Modified and Modified By fields not changed
• No new version (You can pass false to the method just to enable generating a new version)

Update()
• New Version
• Update the modified and modified by fields

UpdateOverwriteVersion()
• No new version.
• Updates the item without creating a new version of the item
• Update the modified time and modified by fields

“If you are stuck trying to update a field for a document library, please be aware of two things in Sharepoint 2007/WSS 3.0.

1. Even if you are NOT using Checked out/checked in, the document still has a SPCheckOutStatus.ShortTerm attached to it for a brief period of time. Trying to SPListItem.Update or SPFile.Item.Update at this point will likely tell you that the file is locked for editing. There is a .checkoutexpires property to check if you absolutely must wait for the item to be checked back in. (e.g. Are they really done with that darn thing?)

2. Even if you do NOT have versioning turned on, you are, in fact, working with a new version of the document. Use SPListItem.SystemUpdate(false) in order to bypass a short term locked document. “[1]

Reference
1. http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.splistitem.systemupdate.aspx

Original Post: http://thesharepoint2010.wordpress.com/2012/09/26/update-systemupdate-and-updateoverwriteversion-splistitem/