Wednesday, September 14, 2011 3:53 PM
It seems that all of our DVWP stopped working this morning. It doesn't seem to depend if the datasource is a list or database. If I open the page with the DVWP in Sharepoint Designer, it opens just fine with data. We get the message, "Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as FrontPage. If the problem persists, contact your Web server administrator."
It is true that these are pages on a SP 2003 server, not 2007, but until this morning, they were just fine. My only lead is that some automatic updates happened over night including KB2494007.
- Moved by Mike Walsh FIN Wednesday, September 14, 2011 4:40 PM SPD questions except wf go to customization (From:SharePoint - Setup, Upgrade, Administration and Operation (pre-SharePoint 2010))
Wednesday, September 14, 2011 8:35 PM
Try to copy all the code from the DVWP and paste it in an empty div in a new .aspx page to see if it works there. If it works, you know it doesn't have anything to do with your code (which it more than likely doesn't).
Check and see if your organization pushed out a Group Policy that might have changed some global settings too.
Thursday, September 15, 2011 10:58 AM
Same happened yesterday on our W2003 server with WSS 2.0 after installing KB 2494007 patch. All DataView WebParts on all websites on that server suddenly stopped working. The symptoms are exactly the same as you described. Pity we can not uninstall that patch :-(
I'm glad I'm not the only one with that problem. Maybe MS will issue a patch for that patch soon ;-)
Mike: Are you sure moving the question from "Setup, Upgrade..." to "Design, Customization..." was a good idea? This is definitely a security patch issue.
Thursday, September 15, 2011 11:16 AM
I have tried creating a brand new blank page with just a data view of the shared documents list and it does the same thing. They work in Sharepoint Designer but fail in sharepoint environment.
In addition, the data source doesn't make a difference. The data views that hit sharepoint lists, SQL Databases, and the AS/400 all behave the same way.
Thursday, September 15, 2011 11:19 AM
I'm sorry for your trouble but I'm glad I'm not alone.
I just got our dev server up to the point where KB2494007 was the only update not applied. DVWP's still worked fine. Had our network guys take a snapshot and applied KB2494007. DVWPs are now broken. I'll have the snapshot restored and call Microsoft.
- Edited by Shoyer Thursday, September 15, 2011 12:27 PM
Friday, September 16, 2011 6:43 PMthis happened to us also! still no solution!
Friday, September 16, 2011 6:44 PMI've been on the phone with MS today once already and am waiting for a call back from the next tier of support. I'll post any solution I get up here (fingers crossed).
Friday, September 16, 2011 6:58 PM
I have been on the phone with our microsoft premier support techs all morning. they said they want to build a test environment of SP 2003 to test it (who knows how long it will take)
i am going to try to escalate it even more.
good luck to us all!
Monday, September 19, 2011 7:58 AMI am having this trouble as well, has anyone heard of a solution to this yet?
Monday, September 19, 2011 10:58 AMMicrosoft set up a test environment this weekend and saw that the patch caused issues. No ETA on the fix yet.
Wednesday, September 21, 2011 11:35 PMHi Again, any further progress from Microsoft? I must admit rebuilding Sharepoint 2003 wasn't really what I was expecting to have to do.
Thursday, September 22, 2011 3:06 PM
i just heard back from microsoft ... unless someone has an extended service contract for sharepoint 2003 - they are going to push the hotfix release out on Dec 13th.
the other solution was to restore the databases back to before the patch was installed and reinstall sharepoint (and loose all work since the backup or manually copy all changes) -- this is not an option for me.
so if ANYONE has an extended service contract for SPS2003 -- please let me know!
Thursday, September 22, 2011 3:48 PMI'm in discussions with another part of microsofts tech support umbrella. I'll let you know if anything comes of it.
Thursday, September 22, 2011 6:18 PM
We have the same situation. We have Microsoft employees helping us the last three days. They found the instructions that caused the error (ddwrt:ConnEncode, ddwrt:FormatDate and ddwrt:NameChanged). Removing this code in our custom pages at least makes them work but loose functionality and they are looking for a way to replace this functionality with an equivalent. Our pages aren’t so extensive but this is not an option for everyone. I post any changes and hope this helps in some way.
Friday, September 23, 2011 1:59 AMWe have this issue as well. Someone mentioned restoring a DB backup prior to when the patch was applied which for most people would mean a loss of data. I just uninstalled WSS 2.0, didn't touch SQL (I'm using SQL Server 2000sp3a) or the databases and then re-installed WSS 2.0 and then installed service pack 3 for WSS 2.0 (that was the only SP or patch I had installed besides the KB2494007 which broke SP) and then went through the restore procedure for WSS 2.0 (minus the database part) and I'm back up and working. My Web Parts are all working now. My SharePoint seems to be working fine so wondering what's wrong with doing what I did. Did that KB2494007 patch actually do something to the database?
Monday, September 26, 2011 2:26 PM
Last Friday we created a virtual server, Installed WSS 2.0 alone (The server with the problem has SharePoint). We configured this server to use the same database as the one that has problems, and extend the server and map existing site pointing to the site with problems and it worked. Apparently the security fix doesn’t affect the database. Now we have an authentication problem in the new server but I think it will be fixed in the next hours. Once it’s fixed this last problem, we have to redirect our users to the new server and remember to turn off automatic updates on the new server.
Tuesday, September 27, 2011 4:53 PMOtero_M, that's interesting because we are having the same exact issue. I haven't figured out the authentication problem yet. It's not an across the board issue just some parts of the site and it affects some people and not others. If you find something please let me know.
Tuesday, September 27, 2011 5:50 PM
Some Microsoft guy found that for some reason the new server authenticates using Kerberos instead of NTLM and they were checking how to change it. I haven’t heard from them today. For some reason if you use the IP address of the server instead of the name, doesn’t give the authentication problem. Finally, for now we’re using the IP address and added the IP address to the Intranet sites in the Internet explorer settings. I hope this helps…
Tuesday, September 27, 2011 8:38 PMActually it looks like KB2494007 does run a couple sql scripts (store.sql and storeup.sql). I'm looking into reverting back to a pre-patch database but I'd be interested to see if you find a fix for the authentication issues.
Wednesday, September 28, 2011 11:47 AM
Nothing new here, I’ll keep you posted.
Wednesday, September 28, 2011 12:47 PM
UH! I'm another victim of this stupid update.
I'm sure, that my authentication was NTLM but after updatig SPS is set on Kerberos. This is the source of all problems on displaying lists.
Hope for quick solution...
Wednesday, September 28, 2011 2:42 PM
The latest I have on this is that the following items can cause this to happen:
We don't use much if any conditional formatting, but everything else we use extensively.
Friday, September 30, 2011 1:17 PM
Try the below mentioned KB article, this should help resolve the issue:
Friday, September 30, 2011 1:31 PM
All of those fixes have been proposed here in the thread (and may have informed the article). Unfortunately, for us anyway,
1) Isn't an option as we have custom apps running on the SP 2003 server,
2) fixing ddwrt:FormatDate as proposed only goes so far as MS has already identified other things besides this formatting that causes the problem, as outlined in my last post (Conditional Formatting, Grouping, Filtering, and Web Part Connections) and
3) Isn't an option because of those same custom apps and the data/workflow they accumulate/control.
Can I mark it as a partial answer?
Anyway, out of desperation, we are now working on rebuilding all the pages we have with DVWPs on our SP 2007 server.
Monday, October 03, 2011 5:57 PM
KM6, We received an e-mail from a SharePoint specialist from Microsoft regarding the authentication problem. The Instructions are:
To use a script to enable NTLM authentication on the virtual server, follow these steps:
1. On the server that is running IIS, click Start, click Run, type cmd in the Open box, and then click OK.
2. Change to the Inetpub\Adminscripts folder.
3. Type the following command, and then press ENTER:
Note In this command, Drive is the drive where Windows is installed.
4. Type the following command, and then press ENTER:
cscript adsutil.vbs get w3svc/##/root/NTAuthenticationProviders
Note In this command, ## is the virtual server ID number. The virtual server ID number of the Default Web site in IIS is 1.
5. To enable NTLM authentication on the virtual server, type the following command, and then press ENTER:
cscript adsutil.vbs set w3svc/##/root/NTAuthenticationProviders "NTLM"
Note In this command, ## is the virtual server ID number.
6. Restart IIS. To do this, follow these steps:
a. Click Start, click Run, type cmd in the Open box, and then click OK.
b. At the command prompt, type iisreset, and then press ENTER.
c. Type exit, and then press ENTER to close the Command Prompt window.
In our case, when we did the IISRESET, the problem came back. We had to repeat the process a second time, including the IISRESET, and it worked.
The address for the article: http://support.microsoft.com/kb/832769
Friday, November 18, 2011 5:49 PMHas there been any update to this? I applied the patch this weekend and all of our DVWP's are broke. This was a huge oversight. I have been able to recreate some form of functionality using the ListView webpart, so at least the users can find what they are looking for, but some of our functionality is on hold until this fix!
Friday, November 18, 2011 6:03 PMI actually just got a call from the support folks at MS I was working with on this. They just received a hotfix designed for 2010 and that is supposed to work for 2003 as well. They are going to be testing it against 2003 and getting back to me. I'll let you know what happens, but wouldn't expect anything for at least a week.
Thursday, December 15, 2011 12:21 PM
does anybody have news about this? See no hotfix on this Patch Tuesday...
Or, did anybody successfully replace ddwrt:FormatDate or ddwrt:GenFireServerEvent with something still usable?
Thursday, December 15, 2011 12:54 PM
Yes ! The hotfix for this was released yesterday (http://support.microsoft.com/kb/2596977)
Download it from http://www.microsoft.com/download/en/details.aspx?id=28371
I have already installed it and it fixed my issues. it doesnt even require a reboot!
- Marked As Answer by Shoyer Thursday, December 15, 2011 3:05 PM
Thursday, December 15, 2011 2:25 PM
I was notified by the support guy I was working with on this issue about the hotfix yesterday but haven't had the opportunity to test it yet. Good to know it worked for you :)
Tested it now. On my test server, it did not ask to reboot.
Ran it on the production server and it did ask to reboot. I said No and it still seems to have fixed the problem.
- Edited by Shoyer Thursday, December 15, 2011 3:05 PM
Friday, December 16, 2011 1:15 PM
thanks a lot! I've also applied on the test environment now and it's OK.