Dave's Technophorical Times

A blog about Microsoft's Technologies!
SharePoint :: MVC :: ASP.NET :: IIS :: SQL Server :: Visual Studio :: MS Access

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!!
"This worked great. The only other thing you need to do that wasn’t mentioned above is go to services in CA and make sure the user profile service is started.
Hope this helps someone else out there cos this took me 5 hours to figure out!
Dave


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:

    $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:

    $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:

    $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:

    $wa = get-SPWebApplication $WebAppName
    $wa.MigrateUsers($true)
    
note 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

After you perform the steps in the previous procedures, you might experience one or more of the following issues.

  • Users who submit valid credentials might be notified that they do not have permissions. If this occurs, the portalsuperuseraccount property and the portalsuperreaderaccount property of the Web application were probably configured prior to migration. If this is the case, you must update the portalsuperuseraccount property and the portalsuperreaderaccount property to use the new claims-based account name. After migration, you can find the new claims-based account name in the Web application policy for the migrated Web application.

  • If existing alerts are not invoked after migration, you might have to delete and recreate the alerts.

  • If Search crawl does not function after migration, make sure the Search crawl account lists the new converted account name. If the new converted account name is not listed, you must manually create a new policy for the crawl account.



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).

    image
  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.

image

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/



This error usually happens if you have two SQL Server instances on the same box and someone removed one at some point.

http://support.microsoft.com/kb/956013

To work around this problem, open a command prompt, type the following command, and then press ENTER:

mofcomp "%programfiles(x86)%\Microsoft SQL Server\number\Shared\sqlmgmproviderxpsp2up.mof"

Note For this command to succeed, the Sqlmgmproviderxpsp2up.mof file must be present in the %programfiles(x86)%\Microsoft SQL Server\number\Shared folder.

The value of number depends on the version of SQL Server:nnn

 Collapse this tableExpand this table
Microsoft SQL Server 2012 110
Microsoft SQL Server 2008 R2 100
Microsoft SQL Server 2008 100
Microsoft SQL Server 2005 90

After you run the Mofcomp tool, restart the WMI service for the changes to take effect. The service name is Windows management Instrumentation.



Use $PSVersionTable.PSVersion to determine the engine version. If the variable does not exist, it is safe to assume the engine is version 1.0.

Note that $Host.Version and (Get-Host).Version are not reliable - they reflect the version of the host only, not the engine. PowerGUI, PowerShellPLUS, etc. are all hosting applications, and they will set the host's version to reflect their product version, which is entirely correct.



The Blogger

Dave Stuart I'm a Developer with a passion for coding. I enjoy the challengers that come with the job! SharePoint is one of my expert areas along with .NET Web Development with MVC and good old MS Access VBA coding. I Blog so that I can remember how I did that way back when; PLUS all this stuff is searchable! I constantly study and run my own business, Dafran Inc. I have passed 22 Microsoft Exams since 1998 when I first jumped on the treadmill of knowledge. I hope that you enjoy this Blog as much as I enjoy updating it. All the very best from Calgary, Alberta, Canada. contact me at linkedin @ dafran.ca

Calendar

<<  March 2017  >>
MoTuWeThFrSaSu
272812345
6789101112
13141516171819
20212223242526
272829303112
3456789

View posts in large calendar

Sign in