Archive for the ‘SharePoint 2007’ Category

Active Directory Migration and SharePoint

June 22, 2012 Leave a comment

Everyone should have to go through an Active Directory migration at least once in their career – you really learn how much you don’t know!


Create a test farm in the old domain that mimics your production farm as much as possible. Pay special attention to the service accounts. Create new accounts for each service account in the production farm, and use them in the test farm. Bring at least one content database over (backup / restore to the testfarm, then attach). Hopefully, you can do this with virtual machines, so that once you get your testfarm up and running you can snapshot it. Run the migration tools and move the testfarm servers to the new domain. Much better to try to figure things out in a testfarm than at 2 AM in a production environment!


We migrated a small SharePoint 2007 farm (1 WFE/App server, 1 DB server). We used the Quest Migration Manager for Active Directory to do the heavy lifting. NOTE – every environment is different. As the saying goes, your mileage may vary.

Migrating Users

For many reasons, we moved users in phases. We also migrated the users and their machines first, and then migrated the servers (this is a debatable decision – things might have been smoother doing the servers first).

When a set of users is migrated, they are now logging in as newdomain\username, but their permissions / ownership / mysite etc. are still olddomain\username. To SharePoint these are two different users.  So, as users are migrated, you must run this STSADM command

stsadm.exe -o migrateuser -oldlogin olddomain\username -newlogin newdomain\username

This replaces the old account SID in the SharePoint databases with the new account SID – everything works. However, we did have the joy of having some ‘roaming’ users who used workstations in different locations. We did not identify them as we should have, and had all sorts of trouble when only one of their workstations was migrated. When they used the other non-migrated workstation they had no SharePoint access (other than Authenticated User). For these people, we manually added their olddomain\username to sites for which they needed access. After the migration was complete, we reran the migrateuser command on their accounts to fix things up.

Migrating SharePoint Servers

SharePoint sites worked correctly after Quest tool processing and migration of the server to the new domain. The tool did a great job creating newdomain\serviceaccounts in SQL Server, and giving them the proper roles and rights. However, the tool does not change the dbo for the SharePoint content databases to the newdomain accounts – this must be done manually.

One thing to note – the Quest tools allows you to do processing before the server is migrated. However, do not do the IIS processing on the WFE before you intend to migrate the server because the AppPool accounts will get changed to the new domain accounts – which will break SharePoint because they will not have DB access.

Running the recommended processing in the Quest tool and migrating the server worked pretty well. SharePoint sites were accessible and functional. However, these issues needed addressing (same ones we found when we tested) –

  • Search did not return any results.
  • Accessing the Central Admin site pages “Manage Applications” and “Operations” returned an Access Denied error.

Fixes were very easy and straightforward.

To fix the Access Denied errors

Logon to a Web Front End server. Open a command prompt, and navigate to the SharePoint 14 hive, bin directory. Run this command –

stsadm -o updatefarmcredentials -identitytype configurableid -userlogin <new domain>\admin_account –password *******

iisreset /noforce

To fix the search problem

Use the Central Admin web site to navigate to the Search Administration page (in the Shared Service Provider). Select “Default content access account” and change the domain on the account listed to the new domain. Start a new crawl (incremental is OK).


Runaway WMIPRVSE.EXE Process

April 27, 2012 Leave a comment


W2K3 machine


SharePoint was running slower than normal. Logged onto the WFE, opened Taskmgr.exe and found that the CPU was pegged. The culprit was the WMIPRVSE process.


After some investigation and restarting services, these are the steps that worked:

  • Kill the runaway process WMIPRVSE.EXE
  • Open Services.msc
  • Restart ScriptLogic CBM Service
  • Restart Window Management Instrumentation (which also restarted Citrx tools for Virtual Machines Service)

Because this server is due for retirement (after migration to SharePoint 2010), no further investigation of why the problem occurred was warranted.

Categories: SharePoint 2007

SharePoint 2007 AD Migration – Test

April 26, 2012 Leave a comment

Project – Test migrate SharePoint 2007 (MOSS) to a new Active Directory domain

  • Test farm has two servers – WFE and Database.
  • Quest Active Directory Migration Manager used to move server to new domain.
  • System accounts created in new domain with same rights on server as old domain accounts (Quest tool).
  • SQL Server Users created with accounts in the new domain with same database rights as the old domain accounts (Quest tool).


NEWDOMAIN\svc_admin_sp2 – can access Shared Service Provider (SSP) pages, but not Operations or Application Management in Central Admin.


Logged in to WFE with ID that could access Operations pages in Central Admin (OLDDOMAIN\svc_admin_sp2)

Run STSADM command to update the farm credentials –

Updates the Web application pool for the SharePoint Central Administration Web site and the Windows SharePoint Services Timer service (SPTimer).>

stsadm -o updatefarmcredentials -identitytype configurableid -userlogin NEWDOMAIN\svc_admin_sp2 -password


Crawl not working.


Default content access account = OLDDOMAIN\svc_admin_sp2

Changed content access account to NEWDOMAINk\svc_admin_sp2 using Search Admin page

Started full crawl

Access OK – no errors in crawl log

Also ran these – which did not fix the problem but where run first and might be needed

Ran STSADM command migrate user for both accounts – had to be logged in as OLDDOMAIN\svc_setup_sp2 – with NEWDOMAIN\svc_setup_sp2 account got an Access Denied error.
Logged in as OLDDOMAIN\svc_setup_sp2 on SRV3 (DB server) – added NEWDOMAIN\svc_admin_sp2 to Farm Admin group (was missing).
Changed application pool accounts – logged in as OLDDOMAIN\svc_setup_sp2

Performed for LINC (the name of the main Web Application) and SSP
Checked Database rights with Magenium SharePoint Farm – all OK. However, the name of the Schema objects is not changed. For example – the NEWDOMAIN\svc_admin_sp2 login owns the OLDDOMAIN\svc_admin_sp2. I don’t think this is a problem.

Microsoft Project 2010 Bug – Save As PDF

February 6, 2012 Leave a comment

If you open an MS Project 2010 file (.MPP) from SharePoint, and try to save it as a PDF using the File > Save As menu, SharePoint opens the client File Dialog. If you select .PDF as the File Type, and then Save, the dialog closes, and a PDF options dialog opens. However, when you select OK on the PDF options dialog, the dialog closes normally BUT the PDF file is not created in the SharePoint document library from which the project was opened! Nor does it save anywhere on the client (that I can find).

The workaround is to use File > Save and Send > Create PDF/XPS Document.

This behavior is the same for MOSS / WSS 2007 and SharePoint 2010. File > Save As only appears to work for .MPP files (even if the name is changed). Using File > Save As with File Types XPS and Project Template files does not work either.

Steps for Creating a Shared Service Provider – MOSS 2007

January 6, 2012 Leave a comment
Login as domain\farmadmin
Open Central Admin SSP page Select Shared Services Administration

(in Quick Launch – left hand navigation pane)


Create New SSP Page = Manage this Farm’s Shared Services

Select New SSP

Configure Shared Service Provider Page = New Shared Services Provider

Enter SSP Name = SharedServices1

Select – Create a new Web application

  • This opens the standard Create New Web Application page
Create New Web Application for SSP Select option = Create new IIS Web site

  • Port = 100
  • Description = SSP – 100
  • Host Header = <blank>
  • Authentication provider = NTLM
  • Allow Anonymous = No
  • SSL = No
  • Load Balance = (default)
  • Select option ‘Create new application pool’
  • Application pool name = SS2P – 100
  • App Pool Account (Configurable) = domain\farmadmin
  • Select option ‘Restart IIS Automatically’
  • Database Name = WSS_Content_SSP
NOTE – Will be returned to ‘Configure Shared Service Provider’ page with an error – this is normal.

Specify New Shared Services Provider

Web application = SSP – 100 (Web App created above)

My Site Location – Select Create New Web Application

Create Web Application for My Site Select option = Create new IIS Web site

  • Port = 101
  • Description = MySites – 101
  • Host Header = <blank>
  • Authentication provider = NTLM
  • Allow Anonymous = No
  • SSL = No
  • Load Balance = (default)
  • Select option ‘Create new application pool’
  • Application pool name = MySites – 101
  • App Pool Account (Configurable) = domain\farmadmin
  • Select option ‘Restart IIS Automatically’

Database Name = WSS_Content_MySite

NOTE – Will be returned to ‘Configure Shared Service Provider’ page with an error – this is normal.
Configure Shared Service Provider (cont.)
Page = New Shared Services Provider


  • SSP Name = Shared Services1
  • Web App = SSP – 100
  • My Site web app = MySites – 101

Relative URL = /

SSP Service Credentials = domain\SVC_SP_ShrdSvc

SSL = No

Verify –

  • Path for index location =E:\Program Files\Microsoft Office Servers\12.0\Data\Office Server\Applications
  • All remaining values are default
Stop Windows SharePoint Services Help Search Central Admin > Operations > Services on server

Select Stop

Select OK on warning dialog

Stop Office SharePoint Server Search Central Admin > Operations > Services on server

Select Stop

Select OK on warning page

Change Associations Select Shared Serviced Administration > Change Associations

  • Shared Services Provider = SharedServices2
  • Web application = select all
Change Default SSP Select Change Default SSP

SSP = SharedServices2

Select OK on warning page

Start Windows SharePoint Services Help Search Central Admin > Operations > Services on server

Select Start

  • Service Account = domain\farmadmin
  • Content Access Account = domain\farmadmin
  • Search Database Name = WSS_Search2_<computer name>
Start Office SharePoint Server Search Central Admin > Operations > Services on server

Select Start

  • Query and Indexing = both checked
  • Farm Search Service Account = domain\farmadmin
Configure Search Select SharedServices2

Select Search Aministration

Select Content Source

  • Schedule Full Craw Weekly, Mon-Friday, 9 PM 
  • Start full crawl = checked
Categories: SharePoint 2007

SharePoint 2007 Search Administration Page Error

January 6, 2012 Leave a comment

Problem – you can open Central Administration, the Shared Service Provider, and the Search Administration page. However, the Active crawls never return, and if you try to select Content Sources you get this error

An error has occurred while accessing the SQL Server database or the Office SharePoint Server Search service. If this is the first time you have seen this message, try again later. If this problem persists, contact your administrator.

SharePoint partly uses SSL name resolution in the background between farm servers, which users generally do not need to be aware of. Evein if you don’t use SSL for the SSP, Microsoft uses it in the background.

1000 is the number of days that the certification will be valid. This problem will start about 1000 days from when you installed the SharePoint farm (about 2 years, 8 months, and a couple weeks).

Solution  – on all servers, run

net stop osearch

selfssl /s:951338967 /v:1000

net start osearch

This will replace expired ssl certificate.

Categories: SharePoint 2007

Cannot Upload, Add, or Edit Anything in a SharePoint Site

November 8, 2011 Leave a comment


If this happens, there can be two causes –

  • The content database has been set offline
  • The site collection has been set to read only

We had the latter happen when our virtual machine host crashed. Everything came back up correctly, but no one could add new documents or list items, or update existing ones. In our case, it was only on the main site collection. Other site collections on the same content database were not effected. Not sure, but the crash might have happened during a backup in which a PowerShell script locks each site collection before performing a site collection backup.

Check Site collection quotas and locks in Central Administration. Make sure you navigate to the offending site collection.