jwhiteuwc
asked on
Sharepoint 2007 and Edit in DataSheet
Hello, we recenlty ran into a little road block with Sharepoint 2007. All of a sudden recently we can no longer edit documents in DATESHEET view. If we selected the document/item and choose EDIT - DATASHEET VIEW it allows us to enter information on, but when we go to save or navigate away from that document it prompts for creditials. No mater what we put in (even administrator) it doesn't accept the changes.
If we go to NEW - NEW ITEM it allows us to make change, add items, etc, so it doesn't seem to be a permissions issue.
I'm at a loss here, were and what should I be checking?
This is happening on all workstations.
If we go to NEW - NEW ITEM it allows us to make change, add items, etc, so it doesn't seem to be a permissions issue.
I'm at a loss here, were and what should I be checking?
This is happening on all workstations.
ASKER
Nope only one site collection. Odd thing is the Administrator account which can alter and change anything still is prompted for username and password when selecting "edit in datasheet". The permissons on the site indicate FULL CONTROL.
Do you think it's a Office 2007 and Sharepoint issue? It seems like no matter what I put in for a username and password it will not accept and apply the changes made in datesheet view.
Verry odd situation.
Do you think it's a Office 2007 and Sharepoint issue? It seems like no matter what I put in for a username and password it will not accept and apply the changes made in datesheet view.
Verry odd situation.
Actually sounds like it might be an NTLM thing - while SharePoint is technically a part of the Office project, and some features have dependencies, if your getting password issues that makes it sound like your not authenticating. I believe it is also in central admin but my memory is getting fuzzy - but you want to make sure that NTLM authentication is enabled.
Is it correct to assume that both clients and server are in the same domain? theres no cross-domain fun going on or anything?
Is it correct to assume that both clients and server are in the same domain? theres no cross-domain fun going on or anything?
ASKER
No cross domain issues, one smalll domain. I did check to make sure NTLM was enabled. The odd thing is we can edit the sheet/file in the standard view, however we cannot in datasheet view which is really odd.
I do recall having run across this same issue when I worked for SharePoint support and I remember it was a kind of goof thing. You mentioned it was across all clients; are all clients the same OS/patch level? (ex. Win7 w/ SP1)
I dont think that this would be it as it is more related to explorer view, but is the WebDAV service running?
OH Wait a second - you are logging in as DOMAIN administrator I am assuming - can you go into that specific site collection and add the same domain administrator as a member specifically to that site collection? I know it sounds a little redundant, but we are dealing with MOSS here after all ;)
I dont think that this would be it as it is more related to explorer view, but is the WebDAV service running?
OH Wait a second - you are logging in as DOMAIN administrator I am assuming - can you go into that specific site collection and add the same domain administrator as a member specifically to that site collection? I know it sounds a little redundant, but we are dealing with MOSS here after all ;)
ASKER
I beleive webdav is running, though uncertain how to check.
Domain admin is already a memeber of the site and has full control. Is that what you are looking for?
Domain admin is already a memeber of the site and has full control. Is that what you are looking for?
webdav is just a service that you can start/stop through the services control panel, or via CLI:
net start webdav
cant guarantee the second will work, but it should, either way I dont think that webdav is really required for dataview to work as dataview is a function of excel, not a function of explorer.
when I mean add the admin as a user, I mean at the site collection level. but lets check at an even more fundamental level - I am working from memory here but Im currently downloading MOSS from MSDN because this is kind of bugging me that I cant remember this!
I am making the assumption that all users and computers are a part of the same Windows domain (as you stated previously)
I also was under the assumption that everyone, computers and users, were previously authenticating with MOSS against the domain just fine, but its starting to sound like this may not be true. Im disappointed that I cant remember the section to check, but do you know where in central admin to check to see your connection to the domain in terms of pulling the list of users and authentication?
Did, by chance, any computer names change that you know of?
Hopfully I will have a MOSS instance stood up in two hours or so
net start webdav
cant guarantee the second will work, but it should, either way I dont think that webdav is really required for dataview to work as dataview is a function of excel, not a function of explorer.
when I mean add the admin as a user, I mean at the site collection level. but lets check at an even more fundamental level - I am working from memory here but Im currently downloading MOSS from MSDN because this is kind of bugging me that I cant remember this!
I am making the assumption that all users and computers are a part of the same Windows domain (as you stated previously)
I also was under the assumption that everyone, computers and users, were previously authenticating with MOSS against the domain just fine, but its starting to sound like this may not be true. Im disappointed that I cant remember the section to check, but do you know where in central admin to check to see your connection to the domain in terms of pulling the list of users and authentication?
Did, by chance, any computer names change that you know of?
Hopfully I will have a MOSS instance stood up in two hours or so
ASKER
YEs, all comptuers and users are part of the same domain.
It's odd, when it prompts it seems to prompt for a username in SERVERNAME.DOMAINNAME.LOCA
I can't seem to find the location to were it would pull authenticate information from. I do see authenication sources and it just says WINDOWS - FORMS and something else. Right now it's Selected as WINDOW - INTEGRATED WINDOWS AUTHENTICAION and SEND Passwords as clear text is NOT checked.
No computer names have changed.
Please let me know if you need any furthe info. Im stumped.
It's odd, when it prompts it seems to prompt for a username in SERVERNAME.DOMAINNAME.LOCA
I can't seem to find the location to were it would pull authenticate information from. I do see authenication sources and it just says WINDOWS - FORMS and something else. Right now it's Selected as WINDOW - INTEGRATED WINDOWS AUTHENTICAION and SEND Passwords as clear text is NOT checked.
No computer names have changed.
Please let me know if you need any furthe info. Im stumped.
Windows-integrated is the same as NTLM, and it sounds like you found the spot I was referring to (under application management ==> authentication providers)
I forgot about an appointment that I have tonight, but was able to get moss installation started.
If you goto site settings at the site collection level and list the users, do you see the domain users that you should? Also, if I recall, content types can have permissions attached to them. That is also accessed through site settings at any level of the site collection or subsites. Does anything look suspect there?
It does bother me about the authentication being addressed as server.domain .... That makes it sounds like you might not be authenticating via domain. have you attempted to login via UNC? (user = \\netbiosdomain\username)
I forgot about an appointment that I have tonight, but was able to get moss installation started.
If you goto site settings at the site collection level and list the users, do you see the domain users that you should? Also, if I recall, content types can have permissions attached to them. That is also accessed through site settings at any level of the site collection or subsites. Does anything look suspect there?
It does bother me about the authentication being addressed as server.domain .... That makes it sounds like you might not be authenticating via domain. have you attempted to login via UNC? (user = \\netbiosdomain\username)
ASKER
No go. Odd thing is I can access the sharepoint fine it's just editing in Datasheet view. Seems like a bug.
OK ... finally got MOSS stood up in VM, the slow SOB anyway ..... Couple things for you .... Firstly, what versions of MS Office are you using? '07? '10? earlier?
Also, any add-ons like Bamboo or anything?
Lastly the fun part... you might want to use one of the following tools, but I would like you to take a look at your ULS logs (they tend to be fairly substantial in size)
http://ulsviewer.codeplex.com/
http://sharepointlogviewer.codeplex.com/
I cant remember which one I used to use, but they both functionally will perform the same in allowing you to view, sort, and organize those ULS logs.
Basically the process to use is to recreate the error situation (edit a file in dataview and attempt to save) and immediately look in the ULS logs (stored on the MOSS Server under %programfiles%\Common Files\Microsoft Shared\Web server extensions\12\LOGS) with one of those tools and ALSO check out your event viewer after the error condition on BOTH the server and client the operation failed on.
It is entirely possible that if you do not find anything, that we will have to turn the logging verbosity up (only temporarily) - that is done in central admin, under the operations tab, in the diagnostic logging section (bottom left) - catagory: all - event:information - trace:verbose - only do this if you dont find anything in the current ULS logs though
I know this sounds like a lot of work, but thats because it kind of is, however given this much information, theres no reason that we shouldnt be able to find whats causing your shenanigans.
Also, any add-ons like Bamboo or anything?
Lastly the fun part... you might want to use one of the following tools, but I would like you to take a look at your ULS logs (they tend to be fairly substantial in size)
http://ulsviewer.codeplex.com/
http://sharepointlogviewer.codeplex.com/
I cant remember which one I used to use, but they both functionally will perform the same in allowing you to view, sort, and organize those ULS logs.
Basically the process to use is to recreate the error situation (edit a file in dataview and attempt to save) and immediately look in the ULS logs (stored on the MOSS Server under %programfiles%\Common Files\Microsoft Shared\Web server extensions\12\LOGS) with one of those tools and ALSO check out your event viewer after the error condition on BOTH the server and client the operation failed on.
It is entirely possible that if you do not find anything, that we will have to turn the logging verbosity up (only temporarily) - that is done in central admin, under the operations tab, in the diagnostic logging section (bottom left) - catagory: all - event:information - trace:verbose - only do this if you dont find anything in the current ULS logs though
I know this sounds like a lot of work, but thats because it kind of is, however given this much information, theres no reason that we shouldnt be able to find whats causing your shenanigans.
ASKER
Thanks this is what is logged as soon as I try and save the file in Datasheet view and it prompts for a username:
10/24/2011 06:37:34.59 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 82 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.59 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 83 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.59 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 84 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.60 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 85 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.60 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 86 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.60 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 88 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.60 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 89 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.60 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 90 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.60 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 91 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.62 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 92 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.62 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 93 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.59 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 82 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.59 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 83 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.59 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 84 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.60 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 85 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.60 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 86 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.60 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 88 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.60 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 89 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.60 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 90 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.60 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 91 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.62 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 92 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
10/24/2011 06:37:34.62 w3wp.exe (0x1488) 0x16EC Windows SharePoint Services General 8m90 Medium 93 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.
ASKER
Forgot to say. That message is logged as long as the dialog box is open to enter credentials.
This is a custom site? Was it developed in house or contracted out? Either way this tool need to.be ean against your sites custom controls and assemblies. Really should have your devs do this as it will throw out a lot of messages:
http://archive.msdn.microsoft.com/SPDisposeCheck
Basically those log entries are saying you have memory leaks.
http://archive.msdn.microsoft.com/SPDisposeCheck
Basically those log entries are saying you have memory leaks.
ASKER
I'm going to try and upgrade to SP2 to see if that fixes the memory leaks, if not, try SP3, if not.... back to the drawing board.
Very agood backup first!
I didnt not know you wernt on the latest patch level, so that could be somthing also. When was the last time tne server was restarted (windows)?
I didnt not know you wernt on the latest patch level, so that could be somthing also. When was the last time tne server was restarted (windows)?
ASKER
Well the SP2 didn't go very well:
This is what is logged:
The schema version (3.1.3.0) of the database WSS_Content on SERVER is not consistent with the expected database schema version (3.1.8.0) on SERVER. Connections to this database from this server have been blocked to avoid data loss. Upgrade the web front end or the content database to ensure that these versions match.
This is what is logged:
The schema version (3.1.3.0) of the database WSS_Content on SERVER is not consistent with the expected database schema version (3.1.8.0) on SERVER. Connections to this database from this server have been blocked to avoid data loss. Upgrade the web front end or the content database to ensure that these versions match.
How many sharepoint servers?
ASKER
1
The log shows it's failing on: The B2B upgrader timer job failed
The log shows it's failing on: The B2B upgrader timer job failed
ASKER
WSS 3.0 It says SP2 is installed, but it didn't install all the way. Go figure.
Lol gotta love shairpoint. Are you able to get to central admin? And you are on MOSS right, not WSS?
ASKER
Sorry, found out today it was WSS 3.0
Yes, i can get to the central admin
Yes, i can get to the central admin
So what we are going to do is detach sbs then reattach the content database. Before moving one step further I would like you to absolutely ensure you have a sql back up of your content database and move the backup copy to a different medium (disk).
It will take me a couple minutes to shuffle my vms around, but ill post tne directions for the detach reattach, dont worry, its easy. Though ill be working with MOSS, there should bw no difference in this operation for WSS
It will take me a couple minutes to shuffle my vms around, but ill post tne directions for the detach reattach, dont worry, its easy. Though ill be working with MOSS, there should bw no difference in this operation for WSS
ASKER
Backing up the Db's now.
once you have good backups (that there is no reason we should need, but better safe than sorry), goto Central Admin, Application Management, and under Web a management, select Content Databases.
On the next screen, make sure that the correct web application is selected, and then click on the database name (Im guessing WSS_Content).
**** Make note of the database name (all of them if more than 1, though i think WSS only allows a single content database)
on the next screen,******* make note of the 'Database Authentication'; if anything but Windows Authentication, we need to retrieve the SQL database username and password.
at the very bottom, hit the check box that says 'Remove Content Database" and hit the OK button with the warning.
Next, you should be back at the Manage Content databases screen and there should be no databases listed; if there are perform the same procedure on all of them.
Next, click add and on the next screen enter the correct, existing content database name and also the authentication data and click ok
after thats done, test it out by surfing to the site
On the next screen, make sure that the correct web application is selected, and then click on the database name (Im guessing WSS_Content).
**** Make note of the database name (all of them if more than 1, though i think WSS only allows a single content database)
on the next screen,******* make note of the 'Database Authentication'; if anything but Windows Authentication, we need to retrieve the SQL database username and password.
at the very bottom, hit the check box that says 'Remove Content Database" and hit the OK button with the warning.
Next, you should be back at the Manage Content databases screen and there should be no databases listed; if there are perform the same procedure on all of them.
Next, click add and on the next screen enter the correct, existing content database name and also the authentication data and click ok
after thats done, test it out by surfing to the site
you also may need to run psconfig again - thats the SharePoint configuration wizard, or your can access it thruogh the %programfiles%\Common Files\Microsoft Shared\Web server extensions\12\bin directory
ASKER
Sounds good. I'm assuming by adding and removing it is updating the databases?
Thank you.
Thank you.
thats correct, thats what is SUPPOSED to happen.
ASKER
No luck! Method not found: 'Microsoft.SharePoint.Admi
ASKER
I think I might be to the point of starting fresh? Uninstall WSS 3 and reinstall?
lol awesome - time for some stsadm work.
http://technet.microsoft.com/en-us/library/cc263422(office.12).aspx
so, need to open a command line (start=> run=> cmd)
and change directory to the bin folder:
cd "\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin"
and then
********* http://2k8r2-1 --- this MUST be the original URL (the name of the web app in central admin) that the content database was attached to
********* wss_content ---- must be the database name as it appears in SQL server
.\stsadm.exe -o addcontentdb -url http://2k8r2-1 -databasename wss_content
http://technet.microsoft.com/en-us/library/cc263422(office.12).aspx
so, need to open a command line (start=> run=> cmd)
and change directory to the bin folder:
cd "\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin"
and then
********* http://2k8r2-1 --- this MUST be the original URL (the name of the web app in central admin) that the content database was attached to
********* wss_content ---- must be the database name as it appears in SQL server
.\stsadm.exe -o addcontentdb -url http://2k8r2-1 -databasename wss_content
ASKER
Thanks. I gave that a try and this is the resposne I received:
wss_content on SERVER contains user-defined schema. Databases must be empty before they can be used. Delete all the tables....
wss_content on SERVER contains user-defined schema. Databases must be empty before they can be used. Delete all the tables....
Jesus MOSS!
OK, next we are going to perform the same command, but after disabling the Web Front End service on the server:
Central Admin => Operations => Services on Server => click on 'Stop' link next to Windows SharePoint Services Web Application
After that has stopped, retry the above command
if it still gives you grief then:
stsadm -o databaserepair -url http://url -databasename wss_content (if it finds anything then add the following switch: -deletecorruption )
OK, next we are going to perform the same command, but after disabling the Web Front End service on the server:
Central Admin => Operations => Services on Server => click on 'Stop' link next to Windows SharePoint Services Web Application
After that has stopped, retry the above command
if it still gives you grief then:
stsadm -o databaserepair -url http://url -databasename wss_content (if it finds anything then add the following switch: -deletecorruption )
ASKER
Well this is how I ended up fixing it. I went into SharePoint Central. Removed the problem site from SharePoint. Disabled the site in IIS. I then went back into SharePoint, recreated another site on a different port and when asked for a database name, i just used the WSS_Content name. This in turn created the new site, but all the customizations were missing. I then went back into IIS and for this site I changed the Port number to match the old port number and Viola!!! it works!.
Now this leaves me right back to were I was before. I still cannot edit in DataSheet view, it now prompts and says "The access web Datasheet is attempting to retreive data from a different domain. You will be redirected to an error page..."
Now this leaves me right back to were I was before. I still cannot edit in DataSheet view, it now prompts and says "The access web Datasheet is attempting to retreive data from a different domain. You will be redirected to an error page..."
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
As a former SharePoint '07 Support Engineer many of these kinds of issues ended up actually being permissions, but not login related - more something like one setting within the site collection, site, web part, etc; in other words, somewhere in the massive mess of hierarchy there's a setting that got flipped.