**Note: this post it limited in scope to the Single Sharepoint VM environment, anything more complicated is frankly beyond my feeble server administration skills.
If you try to install AD and DNS onto a Sharepoint VM after having already installed Sharepoint you run into a range of problems. The first time I tried to fix the problem I fried my environment and had to revert to a snapshot.
First, install AD and DNS as you normally would. Here’s a link to the guide I used.
At this point if you try to hit your Central Administration site or any other Sharepoint site, you’ll get a Service Unavailable message on any page you hit.
I tried the following to bring up something, anything Sharepoint:
None of these works, and if I wasn’t getting the Service Unavailable message, I was getting one that said:
The site you are trying to view does not currently have a default page. It may be in the process of being upgraded and configured.
Looking at the server logs, you see two errors:
Aha! Adding a domain to the mix changes all the user accounts so that your old accounts need to be reconfigured. This is easily done by going into IIS Manager and updating the Identities of all of the app pools to reflect the new, domain enabled accounts.
i.e. servername\MossServiceAcct becomes domainName\MossServiceAcct
Having reconfigured the app pools, trying to hit the server again give you a message that says
The current identity (domainName\MossServiceAcct) does not have write access to ‘c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files’.
You can resolve this easily by navigating to that location and by granting write access to the folder in question (you will need to do this for each unique service account which hits the Temporary ASP.NET Files folder).
Central Admin will loads, but hold on cowboy/girl, you won’t be able to get to any of the pages on the Operations or Application Management tabs.
Some or all identity references could not be translated. at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
Will it never end?
Ultimately I followed the process outlined on two specific web pages (retyping them would be silly)
Following Joel’s tips I got 100% of the way, but the other page a good reference anyways. I found that there were so many passwords to re-enter that I missed a couple (specifically the stsadm -o editssp command) but got there in the end.
Good luck, it’s a painful process, but a possible one. Just be careful and meticulous and you should be okay.
Have you ever had to re-attach a Sharepoint workflow after it has been removed?
It is impossible via the browser (from what I can see) and via designer it is far from obvious how to accomplish this. What you need to do is open the workflow in Sharepoint Designer, click “Finish” and the workflow will re-attach itself. Not very obvious, but it works.
Unfortunately there is no way to associate a workflow with another list unless you open the various workflow xml files change the list guids inside.
I found this to be a total pain to figure out how to fix, but once done, the solution is actually very simple.
Most people doing Sharepoint development will be doing so in a proper networked environment (setup by a proper network admin). In which case this article is unlikely to apply to you and this article, can probably point you in the right direction (hint: you need to set your web.config proxy settings).
I am running a Sharepoint development environment at my house, using VMWare, with a minimal win2k3 setup. I’m not a server admin and I’m conscious hits to performance so the environment is very lightweight. No Domain Controller, no Active Directory. I’m a developer not a sysadmin.
Unfortunately, Sharepoint cares not for my developing ways and when I tried adding an RSS webpart to a Sharepoint page got the following on-screen error:
An unexpected error occured processing your request. Check the logs for details and correct the problem.
Crapola. First I thought dodgy rss.
Then I thought, the IIS account doesn’t have web access.
So then I looked at the million and one “Sharepoint rss proxy” articles on Google to no avail. They all want you to make changes to the defaultProxy entry in your Sharepoint’s web.config.
For some reason, if you don’t have a proxy setup, Sharepoint throws it’s toys out the pram and won’t work. It won’t even try to make a network call (I checked using WireShark). Even when I tried to tell the defaultProxy entry to bypass all addresses, it ignored me.
Setup your own proxy. It’s actually very simple (trust me I hate server admin stuff)
Also important is to make sure you use a proper RSSViewer part instead of a RSSAggregatorWebPart (added manually). The only difference I can see is in the configuration xml, but the latter continued to break even after my changes.
Hopefully this doesn’t up some insane hole in my firewall.
Hope that helps.