Wednesday, July 14, 2010

Accessing SharePoint List Data as XML

REF: http://vspug.com/dwise/2008/01/10/accessing-sharepoint-list-data-as-xml


The other day, I found myself in need of a way to access SharePoint list data as XML but the only method available to me was a simple http GET. This is not too bad, but what can I get from SharePoint via GET? RSS is too limited and scraping the page is too painful and error-prone to even contemplate.

It turns out that there is an option available in 2007 that was carried forward from SharePoint 2003 / FrontPage days: owssvr.dll. But this isn't some forgotten FrontPage artifact, it is still a central part of SharePoint. In fact, if you pull up a list view and then view the source looking for owssvr.dll, you will see that this is the mechanism behind both the Export to Spreadsheet and Open with Access options on the list Actions menu.

How It Works
Simply put together a URL like this:

http://MyServer/[site]/_vti_bin/owssvr.dll?Cmd=Display&List={listGuid}&XMLDATA=TRUE

This will only return the fields that are defined on the default view of the list. If you need specific fields then you need to create a view with those fields and pass the View ID as well, like this:

http://…/owssvr.dll?Cmd=Display&List={listGuid}&view={viewGuid}&XMLDATA=TRUE

Specifying Fields to be Returned
There is also a Query parameter that lets you specify which fields are to be included in the resulting XML, regardless of how the view is defined. For example, if you wanted just to bring back the Title and Status Fields, you would add the field names separated by spaces (URL Encoded, of course) like "&Query=Title%20Status". If you want to return all fields, use an asterisk (*) instead of field names.

http://…/owssvr.dll?Cmd=Display&List={listGuid}&query=Title%20Status&XMLDATA=TRUE

Filtering Data
Regardless of whether you pass a view or use the default it will still use the filter defined by that view. Not bad, but you can trim this data even more by including a filter of your own using the FilterFieldn and FilterValuen arguments in the querystring. These are the same values that are passed when you use the filter options in the column headers of a view which makes it pretty easy to track down exactly what needs to be passed. Simply pull up the view that is your starting point and use the column filters to create your desired filter. Once you have it, grab all of the FilterField and FilterValue items from the querystring and add them on to yours.

http://…/owssvr.dll?Cmd=Display&List={listGuid}&query=Title%20Status&XMLDATA=TRUE&FilterField1=Status&FilterValue1=In%20Progress

For a full list of what can be done with this technique, check out the URL Protocol or the older Using the URL Protocol on MSDN.

Tuesday, July 13, 2010

Importing/Exporting SharePoint Document Libraries to/from the File System

REF: SPIEFolder
REF: http://blog.krichie.com/

SPIEFolder - Allows you to either Import a file system folder (And all files and subfolders) into a SharePoint Document Library, and also export a SharePoint Document Library to the file system for
WSS 2.0/SPS2003 or WSS 3.0/MOSS 2007. This tool completely replicates the document libraries folder hierarchy to the file system when exporting, and replicates the folder hierarchy from the file system to the document library when importing.

Friday, July 9, 2010

Node Manager SSL comunication

REF: Thread: Problem whit Node Manager SSL comunication

Also if you dont want your NodeManager to listen over SSL, you can set

SecureListener=false

And also under machines, change the Listen Type to Plain.

Then the communication between Admin Server and NodeManger will not be over SSL.

Tuesday, July 6, 2010

PSEXEC - Remote control another server with your admin account

psexec \\computer -u domain\admin -p mypass -e cmd.exe

Managing Terminal Services Sessions Remotely

REF: http://weblogs.asp.net/owscott/archive/2003/12/30/Managing-Terminal-Services-Sessions-Remotely.aspx

Look:
qwinsta /server:12.12.12.12

Remove:
rwinsta/server:12.12.12.12 3

For example, let's say that I can't gain access to a server using Terminal Services because both sessions are used up. I can use another server to check the status of the first one. As long as the logged in user has administrative rights on the non-accessible machine I would run this:

qwinsta /server:12.12.12.12

Where 12.12.12.12 is the IP address or name of the non-accessible machine.

This will display something like this:

> qwinsta /server:12.12.12.12
SESSIONNAME USERNAME ID STATE TYPE DEVICE
console 0 Conn wdcon
rdp-tcp 65536 Listen rdpwd
rdp-tcp#470 Bob 1 Active rdpwd
rdp-tcp#471 Jane 3 Active rdpwd

Now I know that Bob and Jane are the two that are logged in. Since Jane left the office 20 minutes ago I know that she forgot to log off. I don't know where Bob is but I only need one session so I'll ignore him for now.

To disconnect Jane's session I would type this:

rwinsta /server:12.12.12.12 3

Notice the 3 which is the session ID I found from using qwinsta above.

Yet another option with W2K3 is a new feature that lets you connect to the desktop directly and gain a 3rd session.

If you're like me, you probably noticed that rwinsta and qwinsta seems like strange names. This came from the Citrix Metaframe days which Terminal Services has descended from. It stands for:

qwinsta = Query WINdows STAtion
rwinsta = Reset WINdows STAtion

One final comment. Microsoft has replaced these two tools with Query but since qwinsta and rwinsta is fully compatible with W2K WinXP and W2K3 I choose to use it instead.