| Ran into a really odd issue where a customer was trying to create a new OneNote 2010 notebook in SharePoint 2007. Everytime he tried to create the notebook in a document library he's get the error below. I could reproduce the issue on my machine as well.
After checkin Document library permissions and about a hundred other items I decided to do some real digging and realized that the OneNote 2010 uses WebDav to communicate with SharePoint. First thing I checked was the WebDav Client on my local machine and wouldn't you know it, service was stopped. So I kicked on that server and Viola....err still broken. Perhaps server related was my next thought.
I took a look at the Web Service Extensions in IIS on the server, and sure enough. Web Dav was "Prohibited" in IIS under the Web Service Extensions. So after looking around to make sure no one saw me enable it in PRODUCTION, kidding.... Always test what it's gonna break in a dev environment first. Anyways I verified that I was having the same issue in Dev, then Set WebDav to "Allowed" in IIS, and was able to create and sync my new workbook with no issues.
So lesson learned, OneNote 2010 and SharePoint need WebDav Allowed in IIS on the SharePoint Servers, as well as the webdav client running on the local machine. (BTW the WebDav client in winxp is a service called WebClient) I haven't dug deep enough into Windows 7 to see what it's actually named on that O/S.
-TRM |
| Let's say you have a powershell script that you've developed and it requires some runtime variable, or specific snapins, and you want to make certain that your script doesn't skip line 20 if line 15 has a null value for a variable etc...
You can actually add the parameter $ErrorActionPreference = "" to your code.
The Parameter can except 4 difference values which are:
Continue (this is the default value and what you get if you don't include this parameter in your script at all)
SilentlyContinue
Inquire
Stop
In my scenario I was working with a custom script and everytime it'd try to load a powershell snap in that was already loaded in my profile, the entire script would die, because my parameter was set as this.
$ErrorActionPreference = "Stop"
I quickly modified it to $ErrorActionPreference = "Inquire"
This way I could see what things it was erroring on, and choose to Halt, or continue on with the script.
A great blog post to follow is here http://tasteofpowershell.blogspot.com/2008/07/handling-errors-in-powershell.html |
| Today I was deploying a solution to a web application and got the error message The process cannot access the file 'MySolutionsName.dll' because it is being used by another process.”
After first giving the normal "What the What?" I checked the solution store and noticed the solution was in Error, and had the same error message listed. Looked like there was some issues with the solution file earlier during the day, either someone deploying it or retracting or maybe both. So after scratching my head and deciding that Uninstalling SharePoint wasn't going to be a good option (just kidding btw), a quick google pointed me to an article below. Referencing a similar issue and giving a quick step on how to figure ou what process is holding your DLL hostage. So I followed the steps; opened up a command prompt and typing in tasklist /M mysolutionheldhostage.dll (replacing the dll name with the name of my DLL). and it returned a list that a powershell process had a hold of my dll. So I opened up task manager, and sure enough a developer was doing something or the other to my dll in powershell. Next steps you could do would be KILLING THE PROCESS, or you could take a much gentler approach like contacting the offending user and asking them if they could close the app. WARNING, "Killing a task by force through the task list is probably not the best idea as it could cause undesired results." You've been warned.
Anyways the developer was done, I killed the powershell process and was able to deploy the solution agian. Post below with a subsequent blog post following.
http://social.technet.microsoft.com/Forums/en-US/sharepoint2010programming/thread/19a71f34-ef6a-4e5d-9c2a-c2f4afe79433
http://www.chaholl.com/archive/2011/01/31/quick-tip-error-occurred-in-deployment-step-lsquoadd-solutionrsquo.aspx
|
|
So it's been a while since I've gotten a new blog up. It's most certainly not for a lack of topics, new and exciting happenings or anything like that. It's primarly been for a lack of extra time to get all these topics and conversations into a presentable form instead of one just long rambling run on sentence.
Well, I think I've finally found some time due to me getting a little break from the office to fly out to my first Technical conference ever, the SPTechCon 2012 Conference in San Francisco. It's been a huge blast so far. Well most of it.
I don't think it's a secret that I haven't been watching the twinkies the way I probably should have been for the past few years. Combine that with the rarity of me taking commercial flights and the tendency to completely forgot how small airplane seats are. I absolutely realize this is NOT the fault of the airline, the seat manufacturer, the engineer who designed the internal layout of the plane, bad sharepoint data on jet liner comfort ratings or anything with me being missed during the last Gallup poll on do I prefer being squished or squishing others. Anyway's the first flight was okay, I wasn't in the middle and there happened to be an entire empty row, where it appeared a family of three overslept, and maybe they purchased the ticket cancellation insurance? I really don't know, but thank you. The second flight I didn't get so lucky or really its more fair to say the person riding on my row didn't get so lucky. I can only apologize to the extremely friendly gentleman in row 4 seat A, and hope you don't happen to have a return flight with me.
So back to SPTechCon 2012. I was able to get in on the first days workshops with Shane Young (@ShanesCows) and Todd Klindt (@ToddKlindt), formally of Sharepoint 911, recently purchased by Rackspace. The workshop was an IT Pro/Sharepoint Admin class, focusing on how to be better administrator of the Sharepoint 2010 platform. There were lots of actual field war stories on things they'd seen, tried, what worked and what didn't. it was a great class especially for someone like myself who works in what I call a very large multi farm environment that was lovingly handed down from one generation of IT resources to another as the previous architects, admins, and engineers have answered the call to new and larger assignments and opportunities. I certainly miss them all, but there were a lot of things I just wasn't sure why we did. kinda like that story of the daughter who cooks a ham, but always cuts off an end of it. When asked why she's does that she says "Well that's how my mom always did it, so its what I learned." Of course after inquiring of the mother why she cut the off the ham before cooking it, the mother says, "It's because my pot was too small, and the entire ham couldn't fit into it." So alot of the things we learned were knowledge that this previous person said do, and as long as we followed it nothing bad happened. well usually nothing bad happened. Anyways this workshop was incredibly helpful in learning why we were cutting the end off the ham...err well why were we following certain operating procedures in our environments. Not just the why, but also helped me to know how to validate that the new and every changing policies we were presently implementing were in line with the things Todd and Shane had seen in the real world already. So this overall was a very helpful session. I have lots of notes that I'll be taking back home with me and hopefully will be able to pass new knowledge down to my team members.
Thats my take on day 1, or really I guess it was the prequel, or pre game, however you want to call it. Sundays Sessions were well worth it. I hope to write and publish more on the sessions on the other days. So stay tuned.
@TechRevMarrell
|
| One thing I noticed with an Anonymous Blog site in Foundation is, the user always gets the default theme. I did some googling today and ran across some info in the comments section of this blog http://www.novolocus.com/2010/04/14/themes-in-sharepoint-2010/
I followed the steps below in my v4.master page and it works for me. :) I noticed that the calendar dates were still using the default css and not using the theme, but adding the blog.css link resolve it for me.
|
|
Well I've moved my site from Office 365. The beta was great and all, but I didn't need my personal site on it. Anyways I should have all my older posting moved over shortly.
|
| So I've spent a little time over the
years doing opensource web development, in particular PHP. And one of my
favorite PHP platforms is CMS Made Simple (CMSMS) CMS Made Simple. Recently I was having an issue
uploading files larger than 2MB using Image Manager. The error I was getting
was "File could not be uploaded. This could be a permissions or Safe mode
problem?"
After doing some checking I decided to check the
config file, and sure enough max upload was set at 2MB, see below. I
adjusted this to 10MB by changing the value to 10000000, and that resolved the
issue.
-------------------------------------------
#Maxium upload size (in bytes)?
$config['max_upload_size'] = 2000000;
-------------------------------------------- |
| Today is day 10 of my staycation. I've been so busy
with non IT things like sleeping in, playing with the kids, and eating
fattening foods that I've almost completely forgotten what SharePoint 2007
Central Admin looks like. :) Honestly, I had planned on spending some
time with family out of state, studying to pass my 70-667, but some life
changing family situations changed things from a vaca to a stayca and am
emphasis on enjoying family and relaxing best we can. Anyways, since the end of
my break is fast approaching I figured I'd better get back into the swing of
things. I think I'll spend some time working on my home dev box and seeing if I
can build some automation for my site monitoring. Hope all is well in IT land
for everyone. |
| The Beginning
Not too long ago I Patched my very large SP2007
environment to the latest CU. (I can hear @ToddKlindt 's voice
in my head right now) The environment had a large number of teamsites lets just
say greater than 1500 and some of these teamsites were pretty large in size,
pushing the 100GB content DB best practice limit. So I decided to apply a trick
I'd learned from a different environment of removing the content databases from
SharePoint, running the patches, then adding the content databases back once
the actual servers were updated. This of course would upgrade the content
database once it was re-added to the Web Application. Everything went great, or
it seemed that way. The upgrade completed in about 3hrs for the entire
environment. The sites I checked all were working correctly and well, the
environment as a whole seemed to be very happy to be patched. I had no idea
what I was to experience in the next couple days.
Excuse me sir?
The next week was going by smoothly until I was
notified of a site collection that was giving a 404 error. Upon a quick
inspection of the site collection list, I could see the site was listed, but
the amount of disk space used was 0 mb. This was very
strange to me, normally if a site was having an issue with the content database
it would be listed in the site collection list, but would no return any
information (site owner, content db, etc...) once it was hightlighted but this
was once. My first thought was maybe something had happened to the default.aspx
file and it wasn't allowing it find the correct content db? (this was a flawed
theory btw) So added a default.aspx page to the site collection got rid of the
404, but now the site was completely blank, as in it looked like a blank site
template. No content anywhere. Just a blank template waiting for data. Around
this time I had reports of more sites showing 404...
Houston we have a problem
At this point I did some major digging, and ran the
enumsites command against the web application and piped the results into an xml
file that I opened with Excel and sorted into a table. I figured one of the
symptoms was the 0MB on storage used so I wanted to see if there were more
sites having the same issues, and sure enough I discovered 4 additional sites
with the storage size set as 0.2mb, and when I tried each link I would get the
404. At this point I began to think there was an issue with the content
databases after patching. So I had the previous backups restored (you did take a backup before patching
right?) and when I would addcontentdb
back into the web app, same issue. It didn't take me but going back a few weeks
to realize that what ever was happening had been there a while.
Ah Ha, there's the issue
It took some work, and a very brilliant
team member of mine figured that we may have orphaned sites in the content
database. Of course before we do patching we check for database corruption and
run the databaserepair parameter, but (here's hindsight) it appears that it
only looks for orphaned items in the sites. We found the great post by
@joeloleson http://www.sharepointjoel.com/Lists/Posts/Post.aspx?ID=291 that showed up how to delete
orphaned sites in our content databases, but the next issue was to prove
whether we had any or not. Amazingly enough someone had run the preupgradecheck
utility against the environment previously and it showed us that there were
orphaned sites in our databases, and sure enough it listed the exact 6 sites
that we were having issues with. So after running enumallwebs per the blog
post above and searching for the sites listed, I found the orphaned sites
listed in the Site Map as True, and the sites that used to work listed in the
Site Map as False. So what occured was somehow and orphan site was
created, and then the correct site created and used. And when I removed the
content database and re-added it, the orphaned site took it's rightful place in
the Site Map, and well there was the cause for our 404. Deleting these orphaned
sites removing the databases and then re-adding them returned the correct sites
into the Site Map resolving the issue.
What did we learn?
Orphaned sites are out there, and could be lurking at
any time to show up and 404 some of your production sites. :) Well maybe that's
not the moral. I believe the moral is the be proactive at watching your content
databases for Orphaned Site Collections, especially in an environment where you
have thousands of site collections. Happy Hunting! |
| I was running the stsadm -o preupgradecheck on my dev
SharePoint 2007 environment and out of no one got an error "An error
occurred while parsing EntityName. Line 43, position 220." I got no
error information in the app or sys logs, and ULS wasn't very helpful for me
anyways. Maybe with verbose turned on it would have shown more, but that's a
different blog. Anyways I did some search and found some posts that made
mention of a rule that the preupgradecheck was using and it having a conflict
with the ampersand character "&". It mentioned checking the
content source names, but of course all of mine did not contain that character.
I then remembered modifying one of the start URL's in a content source at a
developers request. So i checked out that content source url and sure
enough the url included a couple variables including the &
character.
In order to get the preupgradecheck to run
successfully I just removed that ampersand character, and saved the content
source (it wasn't doing any active crawls). The checker completed successfully
and I modified the url in the content source back to the original which
included the & and all is well.
From seeing some other blogs about that similar error
looks like the ampersand isn't your friend with some .net web service calls. |
|
|
|
|
|
|
| |
Welcome to SharePoint Blogs. Use this space to provide a brief message about this blog or blog authors. To edit this content, select "Edit Page" from the "Site Actions" menu. |
|
|
|
|
|