First of all, everything is stupid. That being said, I'm working on converting a set of FormFields in a Drop Down List (DVDropDownList) in a Custom List Form, and ran into the following problem:
Say a user makes selections in one of these custom drop-down lists, and then clicks OK, but the user is not allowed to continue (for example a validation error is found upon postback: a nonexistent user is given in a “people” field on the form)… in this case the drop-downs appear to remain selected but when the form is finally submitted, no data will be added to the list for these fields! The fields just end up lost, recorded as blank entries.
Furthermore, I discovered that any sort of postback preventing the user from moving forward causes the same problem.
The solution? Setting EnableViewState="false" on all of the Drop Down Lists seems to have done the trick. I'm not sure why it works, but maybe it has something do to with my alternate data source for the DDLs conflicting with the original field definitions in the list (which have no selections). Maybe I'll never know. Maybe I don't care.
Saturday, June 26, 2010
Selecting SQL collation for Windows Sharepoint Services 3.0
When pre-installing SQL 2005 database services and databases for use with Sharepoint, choose the correct collation the first time!
Database server collation should be set to "case-insensitive", and the database should be "case-insensitive", "accent-sensitive", "kana-sensitive", and "width-sensitive". Or, put in SQL 2005 terms, make sure you select "Latin1_General_CI_AS_KS_WS" when creating your WSS 3.0 databases. This also goes for the Search (WSS_Search_SERVERNAME) database.
More info: http://technet2.microsoft.com/windowsserver/WSS/en/library/58d28a34-7a84-4564-a4cb-0e6b5425f67e1033.mspx
--pup out
Database server collation should be set to "case-insensitive", and the database should be "case-insensitive", "accent-sensitive", "kana-sensitive", and "width-sensitive". Or, put in SQL 2005 terms, make sure you select "Latin1_General_CI_AS_KS_WS" when creating your WSS 3.0 databases. This also goes for the Search (WSS_Search_SERVERNAME) database.
More info: http://technet2.microsoft.com/windowsserver/WSS/en/library/58d28a34-7a84-4564-a4cb-0e6b5425f67e1033.mspx
--pup out
Dissecting Sharepoint 3.0: Invisible documents and the check-out process
The case of the missing Sharepoint documents: If you require document-check-out in your Sharepoint document library, uploads using Windows Explorer or the “Upload Multiple Documents” tool could have surprising results.
In the Sharepoint document library settings, you have the option to “require check out”. If you choose to “require documents to be checked out before they can be edited”, it is important to note the behavior of freshly uploaded documents.
With “require check out” enabled, only the owner (or person who uploaded the document) gets to see a document until it is actually checked in. Using the standard “Upload” button in the document library, users will be prompted to enter comments and then check in the document. However, anyone using the “Upload Multiple Documents” option (available if you have Microsoft Office 2003 or later installed on your machine), will never be asked if they would like to check the documents in (the same goes for uploading documents using Windows Explorer). As a result, the user may have successfully uploaded the documents to the site, but they all remain checked out. A document that has been uploaded but never checked in retains a ghostly and invisible status allowing it to be seen only by the owner.
Someone with Full Control of the document library (such as the site owner) can see a list of these phantom files by going to Shared Documents > Settings > Checked Out Files. Here one can find a list of all of the mysterious files that have never been checked in - (and are therefore invisible to others). If for some reason the original uploader isn’t available to check in the files, this tool can be used to take ownership of the files so that they may be checked in.
Tinkering under the hood:
In the content database for the site, you can see the behavior of checked out files behind the scenes. Looking at the SQL tables, here are some of the fields that can be of interest when investigating Sharepoint document issues:
The AllDocs Table:
- CheckoutUserId: ties to UserInfo table (tp_ID)
- CheckoutDate: Checkout Date (duh)
- Version: Internal version number
- UIVersionString: Display document version
- IsCurrentVersion: (1=yes, 0=no)
- Level: Checkout status of the file (1=checked in, 2=minor version,255=checked out)
The AllUserData Table: (more document versioning/history)
- tp_IsCurrent: When a file is checked out, tp_IsCurrent is set to false on that file’s record, and a new line is created for the checked-out version of the file (wherein tp_IsCurrent becomes true).
- tp_DirName: The parent directory or document library housing the file
- tp_LeafName: The name of the file
- tp_ContentType: In this case, “Document”
- nvarchar1: Username of the last person that modified the file
- nvarchar2: Username of the person that created the file
- nvarchar3: File extension
- tp_level: this indicates the checkout status of the file (1=checked in, 2=minor - version,255=checked out)
- tp_UIVersionString: Display document version
In the Sharepoint document library settings, you have the option to “require check out”. If you choose to “require documents to be checked out before they can be edited”, it is important to note the behavior of freshly uploaded documents.
With “require check out” enabled, only the owner (or person who uploaded the document) gets to see a document until it is actually checked in. Using the standard “Upload” button in the document library, users will be prompted to enter comments and then check in the document. However, anyone using the “Upload Multiple Documents” option (available if you have Microsoft Office 2003 or later installed on your machine), will never be asked if they would like to check the documents in (the same goes for uploading documents using Windows Explorer). As a result, the user may have successfully uploaded the documents to the site, but they all remain checked out. A document that has been uploaded but never checked in retains a ghostly and invisible status allowing it to be seen only by the owner.
Someone with Full Control of the document library (such as the site owner) can see a list of these phantom files by going to Shared Documents > Settings > Checked Out Files. Here one can find a list of all of the mysterious files that have never been checked in - (and are therefore invisible to others). If for some reason the original uploader isn’t available to check in the files, this tool can be used to take ownership of the files so that they may be checked in.
Tinkering under the hood:
In the content database for the site, you can see the behavior of checked out files behind the scenes. Looking at the SQL tables, here are some of the fields that can be of interest when investigating Sharepoint document issues:
The AllDocs Table:
- CheckoutUserId: ties to UserInfo table (tp_ID)
- CheckoutDate: Checkout Date (duh)
- Version: Internal version number
- UIVersionString: Display document version
- IsCurrentVersion: (1=yes, 0=no)
- Level: Checkout status of the file (1=checked in, 2=minor version,255=checked out)
The AllUserData Table: (more document versioning/history)
- tp_IsCurrent: When a file is checked out, tp_IsCurrent is set to false on that file’s record, and a new line is created for the checked-out version of the file (wherein tp_IsCurrent becomes true).
- tp_DirName: The parent directory or document library housing the file
- tp_LeafName: The name of the file
- tp_ContentType: In this case, “Document”
- nvarchar1: Username of the last person that modified the file
- nvarchar2: Username of the person that created the file
- nvarchar3: File extension
- tp_level: this indicates the checkout status of the file (1=checked in, 2=minor - version,255=checked out)
- tp_UIVersionString: Display document version
Process Info - NPSrvHost.exe
This little-known process has a simple explanation if you are a NetPro ChangeAudior or SecurityManager user...
NPSrvHost.exe is the NetPro Compliance Agent service process. It may or may not be using an interesting amount of memory (in my case, a fascinating amount of memory), but fear not, it is nothing foreign so long as you are a NetPro user.
More Info: http://netpro.com
NPSrvHost.exe is the NetPro Compliance Agent service process. It may or may not be using an interesting amount of memory (in my case, a fascinating amount of memory), but fear not, it is nothing foreign so long as you are a NetPro user.
More Info: http://netpro.com
Broken ASP.NET applications in Vista / IIS 7.0
When publishing an ASP.NET app to your IIS 7.0 server, HTTP 500.19 Error messages might indicate a broken IIS registration for the .NET Framework
Who doesn't love a good Internal Server Error? How about this beauty?
This error can spew forth if you're trying to publish your ASP.NET w/ AJAX application to IIS 7.0 and something is amiss with your .NET 2.0 (or possibly 3.0 or 3.5) registration in IIS.
It may be time to re-register the .NET framework in IIS with this command:
%windir%\Microsoft.NET\Framework\v(.NET VERSION HERE)\aspnet_regiis.exe -i
However, if you're in the mood to tinker, you can try editing the %windir%\System32\inetsrv\config\applicationHost.config file, where you'll find a line that reads:
Just change this to "Allow" if your error referred to the "" section in your web.config file.
Similarly, if the error was really about the "" section of the web.config, then look at changing this line to "Allow":
If things are truly not well with your .NET registration, then you might still see this kind of an error:
... and if that's the case, it's probably time to stop messing around under the hood and hope that the "aspnet_regiis.exe -i" command solves your problems. In Vista, .NET is tightly intertwined with the operating system, so reinstall attempts can result in tail-chasing and messages like "Error: Product already installed . . . This product is already installed as part of the operating system."
Who doesn't love a good Internal Server Error? How about this beauty?
| HTTP Error 500.19 - Internal Server Error | |
| The requested page cannot be accessed because the related configuration data for the page is invalid. | |
| Detailed Error Information | |
| Module | IIS Web Core |
| Notification | BeginRequest |
| Handler | Not yet determined |
| Error Code | 0x80070021 |
| Config Error | This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false". |
| Config File \\?\C:\inetpub\wwwroot\web.config | |
This error can spew forth if you're trying to publish your ASP.NET w/ AJAX application to IIS 7.0 and something is amiss with your .NET 2.0 (or possibly 3.0 or 3.5) registration in IIS.
It may be time to re-register the .NET framework in IIS with this command:
%windir%\Microsoft.NET\Framework\v(.NET VERSION HERE)\aspnet_regiis.exe -i
However, if you're in the mood to tinker, you can try editing the %windir%\System32\inetsrv\config\applicationHost.config file, where you'll find a line that reads:
Just change this to "Allow" if your error referred to the "
Similarly, if the error was really about the "
If things are truly not well with your .NET registration, then you might still see this kind of an error:
| HTTP Error 404.3 - Not Found | |
| The page you are requesting cannot be served because of the extension configuration. If the page is a script, add a handler. If the file should be downloaded, add a MIME map. | |
| Detailed Error Information | |
| Module | StaticFileModule |
| Notification | ExecuteRequestHandler |
| Handler | StaticFile |
| Error Code | 0x80070032 |
... and if that's the case, it's probably time to stop messing around under the hood and hope that the "aspnet_regiis.exe -i" command solves your problems. In Vista, .NET is tightly intertwined with the operating system, so reinstall attempts can result in tail-chasing and messages like "Error: Product already installed . . . This product is already installed as part of the operating system."
Phantom Web Parts in Sharepoint 3.0/2007
What can you do if you have uninstalled a web part, but it remains in your list of "All Web Parts"? Unable to delete a web part?
A failed installation or ungraceful removal of a web part from Sharepoint can result in a web part continuing to be available in the "All Web Parts" list, and yet not truly be installed or functioning. This could even prevent the proper re-installation of said web part until the cause of the tie-up is found.
First, check and make sure the web part has truly been uninstalled. Run stsadm.exe -o enumwppacks at the command line on your Sharepoint server for a list of currently installed web part .cab packages. (if you don't already have it handy, stsadm.exe can be found in the %windir%\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN directory).
For example, if you are having this problem with the KWizCom.ListMarquee web part (which was the case for me), you should see a .cab file like "listmarquee_deploy.cab" listed for your site. If you do, you should be able to use this command to remove it: stsadm.exe -o deletewppack -name -url .
If the .cab file related to the troublesome web part is not listed, then make your way into the virtual directory for your Sharepoint web, and look at the wpcatalog directory (\VirtualDirectories\\wpcatalog). If you see a .dwp file associated with the web part here, delete it. Now, make sure you're displaying hidden files and folders, and enter the wpcatalog\_vti_cnf directory. It is likely that you will find a .dwp file here for the lingering web part (in my example this would be, "KWizCom.ListMarquee_1.0.0.0__30fb4ddbec95ff8f_ListMarquee.dwp"). Go ahead and delete this file.
Hopefully this will clear up the sticky web part entry and either permit re-installation or allow everyone to go their separate ways.
A failed installation or ungraceful removal of a web part from Sharepoint can result in a web part continuing to be available in the "All Web Parts" list, and yet not truly be installed or functioning. This could even prevent the proper re-installation of said web part until the cause of the tie-up is found.
First, check and make sure the web part has truly been uninstalled. Run stsadm.exe -o enumwppacks at the command line on your Sharepoint server for a list of currently installed web part .cab packages. (if you don't already have it handy, stsadm.exe can be found in the %windir%\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN directory).
For example, if you are having this problem with the KWizCom.ListMarquee web part (which was the case for me), you should see a .cab file like "listmarquee_deploy.cab" listed for your site. If you do, you should be able to use this command to remove it: stsadm.exe -o deletewppack -name
If the .cab file related to the troublesome web part is not listed, then make your way into the virtual directory for your Sharepoint web, and look at the wpcatalog directory (
Hopefully this will clear up the sticky web part entry and either permit re-installation or allow everyone to go their separate ways.
How Monitor Sharepoint Search Service / Crawl Activity
Unfortunately, if the Sharepoint Search Service breaks or stops crawling sites, nobody finds out until a user complains that documents are missing from their searches. Until NOW!
Since there is no feedback generated when the Sharepoint 3.0/2007 Search Service fails, a problem that affects the daily (or hourly, etc.) crawl of the site will go unnoticed since the search function itself still works. However, since new documents and pages are not being crawled, the search function will be less accurate with each passing day. A status of "Started" on the "Windows SharePoint Services Help Search" service in the Central Administration console means nothing since it remains "Started" regardless of whether crawls are actually taking place.
Here's what can be done: Go to your SQL server (or Sharepoint server if they are one and the same) and add the following stored procedure to your search database (usually called WSS_SEARCH_SERVERNAME). This procedure will check the MSSCrawlHistory table:
CREATE PROC sp_notifyifnocrawl
AS
/* 4/3/2008 - Knowledge Pup - Confirms that there has been Crawl activity in last seven days. If not, e-mails recipient below */
DECLARE @messagehtml NVARCHAR(MAX) ;
IF (SELECT count(*) FROM msscrawlhistory
WHERE DATEDIFF(dd,requesttime,getdate()) < 3 /* crawl activity in last 3 days */
and status = 11 ) = 0 /* Status 11 = Completed crawl */
BEGIN
SET @messagehtml =
N'Sharepoint Search Warning' + CONVERT(char, GETDATE()) + '' +
N'No Sharepoint Search crawl activity in last 3 days' +
N'Please confirm that search service is still operational';
EXEC msdb.dbo.sp_send_dbmail @recipients='user_here@domain_here.com',
@subject = 'Sharepoint Problem: no search crawl activity',
@body_format = 'HTML',
@body = @messagehtml,
@profile_name = 'SQL_email_profile_here';
END
(Note that this example uses SQL 2005, and a different e-mail technique will need to be substituted for other versions)
Modify the line that defines "@recipients" to reflect the corrent e-mail address, and change the "@profile_name" line at the end to point to a SQL mail profile that has been previously created.
Next, create a job under SQL Server Agent that will run this stored procedure once a day. If the crawl process has been dead for over three days you will get an e-mail notifying you of this fact.
Since there is no feedback generated when the Sharepoint 3.0/2007 Search Service fails, a problem that affects the daily (or hourly, etc.) crawl of the site will go unnoticed since the search function itself still works. However, since new documents and pages are not being crawled, the search function will be less accurate with each passing day. A status of "Started" on the "Windows SharePoint Services Help Search" service in the Central Administration console means nothing since it remains "Started" regardless of whether crawls are actually taking place.
Here's what can be done: Go to your SQL server (or Sharepoint server if they are one and the same) and add the following stored procedure to your search database (usually called WSS_SEARCH_SERVERNAME). This procedure will check the MSSCrawlHistory table:
CREATE PROC sp_notifyifnocrawl
AS
/* 4/3/2008 - Knowledge Pup - Confirms that there has been Crawl activity in last seven days. If not, e-mails recipient below */
DECLARE @messagehtml NVARCHAR(MAX) ;
IF (SELECT count(*) FROM msscrawlhistory
WHERE DATEDIFF(dd,requesttime,getdate()) < 3 /* crawl activity in last 3 days */
and status = 11 ) = 0 /* Status 11 = Completed crawl */
BEGIN
SET @messagehtml =
N'Sharepoint Search Warning' + CONVERT(char, GETDATE()) + '' +
N'No Sharepoint Search crawl activity in last 3 days' +
N'Please confirm that search service is still operational';
EXEC msdb.dbo.sp_send_dbmail @recipients='user_here@domain_here.com',
@subject = 'Sharepoint Problem: no search crawl activity',
@body_format = 'HTML',
@body = @messagehtml,
@profile_name = 'SQL_email_profile_here';
END
(Note that this example uses SQL 2005, and a different e-mail technique will need to be substituted for other versions)
Modify the line that defines "@recipients" to reflect the corrent e-mail address, and change the "@profile_name" line at the end to point to a SQL mail profile that has been previously created.
Next, create a job under SQL Server Agent that will run this stored procedure once a day. If the crawl process has been dead for over three days you will get an e-mail notifying you of this fact.
File Replication Service Broken? Of course!
Every so often, one of your domain controllers (or other servers, if you're making use of FRS shares) will stop replicating Group Policies, NETLOGON scripts, or other data. Oh yes, it will happen. And if it has already happened, oh yes, it will happen again. Here's the not-to-miss quick fix.
If you have multiple Windows 2000/2003 Server domain controllers and you have received complaints that group policies are only intermittently applied to users or computers, you may be a victim of a File Replication Services burnout. This can affect the replication of policies, scripts, files in the SYSVOL/NETLOGON directories, and anything else you are replicating with the FRS service. FRS burnout can happen as a result of network drops, file corruption, or maybe it's just Tuesday – sometimes it just happens on Tuesday.
The best fix that just doesn't get nearly enough press on the Internets (but actually appears as a recommendation in the event viewer if you happen to be the lucky recipient of Event ID: 13568, a.k.a. the JRNL_WRAP_ERROR) is to go through the following steps:
1. Log in to the server with the suspected replication problem (Replmon, with its Show Group Policy Object Status can be a fantastic resource in the case of FRS burnout)
2. Navigate to this key in Regedit: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters
3. Edit (or add as a DWORD value) "Enable Journal Wrap Automatic Restore", and set to 1
4. Wait for at least 5 minutes. While you’re at Starbucks, the NTFRS service will remove the system from the replication set, remove the local copy of the replicated data, and place the data in a backup folder called, “NtFrs_PreExisting___See_EventLog”, which you can delete when all of this is over.
5. When you’ve returned, set the value back to 0.
In theory, you should see positive event viewer items such as Event ID: 13553, which signals that the replication relationships have been rebuilt. Replication has only just started so depending on how much data you have in the replicated directories, it could already be finished, or it may be a while before the fresh replication is complete.
I’ve seen some pretty odd replication problems, but going through this process on the right replica members usually sorts things out.
May you never again be a victim of FRS burnout. But, oh yes, you will be.
If you have multiple Windows 2000/2003 Server domain controllers and you have received complaints that group policies are only intermittently applied to users or computers, you may be a victim of a File Replication Services burnout. This can affect the replication of policies, scripts, files in the SYSVOL/NETLOGON directories, and anything else you are replicating with the FRS service. FRS burnout can happen as a result of network drops, file corruption, or maybe it's just Tuesday – sometimes it just happens on Tuesday.
The best fix that just doesn't get nearly enough press on the Internets (but actually appears as a recommendation in the event viewer if you happen to be the lucky recipient of Event ID: 13568, a.k.a. the JRNL_WRAP_ERROR) is to go through the following steps:
1. Log in to the server with the suspected replication problem (Replmon, with its Show Group Policy Object Status can be a fantastic resource in the case of FRS burnout)
2. Navigate to this key in Regedit: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters
3. Edit (or add as a DWORD value) "Enable Journal Wrap Automatic Restore", and set to 1
4. Wait for at least 5 minutes. While you’re at Starbucks, the NTFRS service will remove the system from the replication set, remove the local copy of the replicated data, and place the data in a backup folder called, “NtFrs_PreExisting___See_EventLog”, which you can delete when all of this is over.
5. When you’ve returned, set the value back to 0.
In theory, you should see positive event viewer items such as Event ID: 13553, which signals that the replication relationships have been rebuilt. Replication has only just started so depending on how much data you have in the replicated directories, it could already be finished, or it may be a while before the fresh replication is complete.
I’ve seen some pretty odd replication problems, but going through this process on the right replica members usually sorts things out.
May you never again be a victim of FRS burnout. But, oh yes, you will be.
How to Purge the Sharepoint Search Database
If you need to stop and restart the Windows SharePoint Services Search Service in SharePoint 3.0/2007, you will be required to first completely purge the database and all stored procedures manually. Here's a quick way to do it.
When attempting to stop and restart the Windows SharePoint Services Search Service by simply clicking on "stop" and then "start" (seems reasonable), you will be confronted with this error after filling out the settings form:
This happens because SharePoint wants to build the search database from scratch after the service has been stopped. One solution is to just drop the database and re-create it, but that can be a big hassle if you have a separate database server in your SharePoint farm and everything is set up just the way you like it. It's hard to say why SharePoint wants to make such a big deal out of staring the service, but I'm sure there is a reasonable explanation. Anyway, here is a quick script you can run against the database after stopping it. This will delete all of the tables and stored procedures (there are no views). You will need to run it at least three times to take care of all of the table dependencies... and please make sure you run it against the right database or significant anguish could result!)
/* Delete tables and procedures from WSS_Search_* database
run this set of commands several times to ensure that all dependences removed
WARNING: wipes out tables and stored procedures! Make sure you run it against the right database!
Knowledge Pup - 2008 */
exec sp_msforeachtable "drop table ? print '? has been dropped.' "
declare @dropproc nvarchar(max)
declare @numprocs int
declare @pos int
declare @procs table (rowcnt int identity (1,1) primary key not null, pname varchar(100))
insert into @procs select name from sysobjects where xtype = 'P'
select @numprocs = count(*) from @procs
select @pos = 1
while @pos <= @numprocs
begin
select @dropproc = 'drop procedure ' + pname from @procs where rowcnt = @pos
execute sp_executesql @dropproc
select @pos = @pos + 1
end
When attempting to stop and restart the Windows SharePoint Services Search Service by simply clicking on "stop" and then "start" (seems reasonable), you will be confronted with this error after filling out the settings form:
| WSS_Search_SERVERNAME on SERVER contains user-defined schema. Databases must be empty before they can be used. Delete all of the tables, stored procedures and other objects or use a different database. |
This happens because SharePoint wants to build the search database from scratch after the service has been stopped. One solution is to just drop the database and re-create it, but that can be a big hassle if you have a separate database server in your SharePoint farm and everything is set up just the way you like it. It's hard to say why SharePoint wants to make such a big deal out of staring the service, but I'm sure there is a reasonable explanation. Anyway, here is a quick script you can run against the database after stopping it. This will delete all of the tables and stored procedures (there are no views). You will need to run it at least three times to take care of all of the table dependencies... and please make sure you run it against the right database or significant anguish could result!)
/* Delete tables and procedures from WSS_Search_* database
run this set of commands several times to ensure that all dependences removed
WARNING: wipes out tables and stored procedures! Make sure you run it against the right database!
Knowledge Pup - 2008 */
exec sp_msforeachtable "drop table ? print '? has been dropped.' "
declare @dropproc nvarchar(max)
declare @numprocs int
declare @pos int
declare @procs table (rowcnt int identity (1,1) primary key not null, pname varchar(100))
insert into @procs select name from sysobjects where xtype = 'P'
select @numprocs = count(*) from @procs
select @pos = 1
while @pos <= @numprocs
begin
select @dropproc = 'drop procedure ' + pname from @procs where rowcnt = @pos
execute sp_executesql @dropproc
select @pos = @pos + 1
end
Managing SharePoint 3.0 Alert Subscriptions
Sharepoint provides you with the handy function of subscribing to alerts generated when list content is added or changed. But what if you need to manage and review your alerts for the entire site?
In a calendar, documents library, or other list, you can choose to receive e-mail notifications for changed items by visiting the Actions menu and selecting "Alert Me”. Furthermore, if you want to modify your existing alerts, you can go to this same screen and then click on "View my existing alerts on this site". The problem comes when you, as an administrator of a site, want to review and manage everyone’s alerts.
Time to crack open Query Analyzer (or SQL Server Management Studio) and look at your content database (usually WSS_Content_SiteNameHere). The ImmedSubscriptions table houses all of the immediate alerts that have been set up by users, which you can delete or tweak if necessary. Here are some of the useful table columns:
Id: GUID for the alert
ListId: links to the AllLists table
UserId: links to the UserInfo table
UserEmail: email address of the alert recipient
SiteUrl, WebUrl, ListUrl: determines the location of the list to which the alert is associated
Alert Title: arbitrary name for the alert
In a calendar, documents library, or other list, you can choose to receive e-mail notifications for changed items by visiting the Actions menu and selecting "Alert Me”. Furthermore, if you want to modify your existing alerts, you can go to this same screen and then click on "View my existing alerts on this site". The problem comes when you, as an administrator of a site, want to review and manage everyone’s alerts.
Time to crack open Query Analyzer (or SQL Server Management Studio) and look at your content database (usually WSS_Content_SiteNameHere). The ImmedSubscriptions table houses all of the immediate alerts that have been set up by users, which you can delete or tweak if necessary. Here are some of the useful table columns:
Id: GUID for the alert
ListId: links to the AllLists table
UserId: links to the UserInfo table
UserEmail: email address of the alert recipient
SiteUrl, WebUrl, ListUrl: determines the location of the list to which the alert is associated
Alert Title: arbitrary name for the alert
Windows Vista: Unable to Connect to Console through Remote Desktop?
Microsoft has a treat for those of us that have been using mstsc.exe to connect to the console session on a server.
Previously, the "/console" flag with mstsc.exe would get you a console RDP session on a server. But this flag is now completely ignored in Vista! (A feature that has the fun effect of making you think you might have a console session when you don't) Now, to get an actual console session, you must use the "admin" flag: mstsc.exe /admin servername.
Oh, and this just in: in future releases of Windows, the "Start Menu" will be renamed to "Recycle Bin", and the "Recycle Bin" will be referred to as the "Funk Button". Also, the backspace key on your keyboard will shut down the system.
Previously, the "/console" flag with mstsc.exe would get you a console RDP session on a server. But this flag is now completely ignored in Vista! (A feature that has the fun effect of making you think you might have a console session when you don't) Now, to get an actual console session, you must use the "admin" flag: mstsc.exe /admin servername.
Oh, and this just in: in future releases of Windows, the "Start Menu" will be renamed to "Recycle Bin", and the "Recycle Bin" will be referred to as the "Funk Button". Also, the backspace key on your keyboard will shut down the system.
SQL Reporting Services: That Misbehaving Report
If you have one particular report in SQL Reporting Services (2000 or 2005) that mysteriously prompts for credentials, or refuses to run without any particular reason given, take a look at the server logs. It’s possible you may be running into a memory-related error.
There are a number of reasonable explanations if none of the reports will run in SQL Reporting Services, but what if the problem is just with one particular report? In my case, this rouge report would just prompt for credentials (the server was set to Windows Authentication only), and refuse to display regardless of the credentials entered.
Take a look at the Event Viewer. You may or may not see an Event ID: 1011 (“A process serving application pool 'ReportServer Pool' suffered a fatal communication error with the World Wide Web Publishing Service. The process id was '1284'. The data field contains the error number.”). If this is the case, dive into the latest ReportServer log (usually located in c:\Program Files\Microsoft SQL Server\MSSQL.2\Reporting Services\LogFiles). This is where you might find this error:
In this case, either the report is so beefy that it’s taking up way too much memory, or maybe your Reporting Services box needs a memory boost. You can try raising the MemoryLimit or MaximumMemoryLimit values as described here: http://support.microsoft.com/kb/909678 (don’t raise the MemoryLimit value to over 90% unless you’re into explosions)
In my case, I found I was able to economize on the design on my report (I had a number of unnecessary parameters), and once I simplified it, it ran just fine.
Good luck and good reporting.
There are a number of reasonable explanations if none of the reports will run in SQL Reporting Services, but what if the problem is just with one particular report? In my case, this rouge report would just prompt for credentials (the server was set to Windows Authentication only), and refuse to display regardless of the credentials entered.
Take a look at the Event Viewer. You may or may not see an Event ID: 1011 (“A process serving application pool 'ReportServer Pool' suffered a fatal communication error with the World Wide Web Publishing Service. The process id was '1284'. The data field contains the error number.”). If this is the case, dive into the latest ReportServer log (usually located in c:\Program Files\Microsoft SQL Server\MSSQL.2\Reporting Services\LogFiles). This is where you might find this error:
| ERROR: Found System.OutOfMemoryException exception: Microsoft.ReportingServices.Diagnostics.Utilities.InternalCatalogException: An internal error occurred on the report server. See the error log for more details. ---> System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown. |
In this case, either the report is so beefy that it’s taking up way too much memory, or maybe your Reporting Services box needs a memory boost. You can try raising the MemoryLimit or MaximumMemoryLimit values as described here: http://support.microsoft.com/kb/909678 (don’t raise the MemoryLimit value to over 90% unless you’re into explosions)
In my case, I found I was able to economize on the design on my report (I had a number of unnecessary parameters), and once I simplified it, it ran just fine.
Good luck and good reporting.
Friday, June 25, 2010
Wayward Users in SQL 2000/2005/2008
After migrating a database between database servers (such as between a 2000 and 2005 SQL server instance), user relationships at the server and database level tend to become disjointed.
After backing up and then restoring a database on a new SQL 2000 or 2005 server, users may lose their access even though the user appears to be defined at both the server and database levels. However, the GUID relationship between these levels has been broken, and these may no longer be considered the same people. Here is a quick way to find out if your user relationships have become fractured:
Run this command: EXEC sp_change_users_login 'Report'
A list of users will be returned at are either not defined at the server level, or don’t have a relationship with the identically-named account at the server level:
For each of these users that are already defined at the server level (but just don’t happen to have a relationship with these database-level accounts), run this command:
EXEC sp_change_users_login 'Auto_Fix', 'usernamehere'
Or, if the account doesn’t exist server-wide yet, then run this:
EXEC sp_change_users_login 'Auto_Fix', 'usernamehere', 'loginnamehere', 'passwordhere'
If you run EXEC sp_change_users_login 'Report' again, you should see that the users are absent from the report, and all should be well.
After backing up and then restoring a database on a new SQL 2000 or 2005 server, users may lose their access even though the user appears to be defined at both the server and database levels. However, the GUID relationship between these levels has been broken, and these may no longer be considered the same people. Here is a quick way to find out if your user relationships have become fractured:
Run this command: EXEC sp_change_users_login 'Report'
A list of users will be returned at are either not defined at the server level, or don’t have a relationship with the identically-named account at the server level:
| walterw | 0x52C270B1CB7BD9008127009027I88F04 |
| girtrudep | 0x71502CC34E5BD4118678009027I88F04 |
| juanq | 0xB02589B294564D51180F1009027I88F04 |
For each of these users that are already defined at the server level (but just don’t happen to have a relationship with these database-level accounts), run this command:
EXEC sp_change_users_login 'Auto_Fix', 'usernamehere'
Or, if the account doesn’t exist server-wide yet, then run this:
EXEC sp_change_users_login 'Auto_Fix', 'usernamehere', 'loginnamehere', 'passwordhere'
If you run EXEC sp_change_users_login 'Report' again, you should see that the users are absent from the report, and all should be well.
Making SharePoint Links Open in a New Window
Out of the box, Sharepoint Links lists don't give you the ability to open links in a new window (i.e. no access to the "target" attribute of the link). But a quick SharePoint Designer (or FrontPage) trick can fix that.
If you need your links in a Links list to open in a new window, you can do the following:
- Open the view document for the list in Sharepoint Designer (e.g. /Lists/Links/AllItems.aspx)
- Right-click on the List View Web Part (WebPartPages:ListViewWebPart) and Click on the option that says, "Convert to XSLT Data View"
- Right-click on the text of one of the links and choose "Hyperlink Properties"
- Click the "Target Frame" button on the right and pick "New Window"
- Click OK and then OK!
- Save the document
You'll notice that this is an all-or-nothing fix: all present and future links on this page will open in a new window.
If you need your links in a Links list to open in a new window, you can do the following:
- Open the view document for the list in Sharepoint Designer (e.g. /Lists/Links/AllItems.aspx)
- Right-click on the List View Web Part (WebPartPages:ListViewWebPart) and Click on the option that says, "Convert to XSLT Data View"
- Right-click on the text of one of the links and choose "Hyperlink Properties"
- Click the "Target Frame" button on the right and pick "New Window"
- Click OK and then OK!
- Save the document
You'll notice that this is an all-or-nothing fix: all present and future links on this page will open in a new window.
VPN Users in Windows XP - A Case of Wandering DNS
When on VPN, are your DNS requests heading off to the ISP instead of your internal DNS servers? Been over the settings a hundred times, and everything is perfect?
For some reason an XP workstation may decide never to use the DNS servers on a VPN connection no matter how hard you try. It turns out that this little trick to change the network connection binding order can make a difference (even if you've already tried changing the binding order in the networking "Advanced" settings):
Open Regedit and make your way to: HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\TCPIP\LINKAGE\BIND. Now cut the line in the multi-string value that reads "\Device\NdisWanIp" and paste it in a new line above all of the other device entries.
Try re-establishing your VPN connection, and perhaps if you're lucky, the nightmare will end.
Subscribe to:
Posts (Atom)