Yet another interesting MSDN forum post I answered.  A user asked how they could programmatically determine the installation directory of SharePoint.  After multiple searches on the web, etc. I stumbled on the answer….read the registry!

Here is some sample code (i havent actually tested this code but the logic is sound):

using Microsoft.Win32;
...
RegistryKey masterKey = Registry.LocalMachine.CreateSubKey("SOFTWARE\\Microsoft\\Office Server\\12.0");
if (masterKey == null)
{
   Console.WriteLine ("Null Masterkey!");
}
else
{
   Console.WriteLine ("MyKey = {0}", masterKey.GetValue ("InstallPath"));
}
masterKey.Close();

 

the only issue I see here is that depending your farm (a 5 server farm for example), is if you install SharePoint in a different directory on each web front end.  In that case, depending on what server the request gets processed, you may get a different location that if you run the same request on a different WFE where the install directory was different. 

Honeslty I've never run into a case where the install directory was different on each WFE since most WFE's mirror each other, just thought I would throw it out there to you as well as the fact that it would just be bad practice to have the WFE’s use different install directories.

Another user responded to the post and said you could do it using the SPUtility class’s GetGenericSetupPath method, which seems a bit more logical and using the SharePoint API.

using Microsoft.SharePoint.Utilities;
...
string featurePath = SPUtility.GetGenericSetupPath("12");

Posted in:   Tags: , ,

SharePoint has issues with using keywords "today" and "my". Due to this issue, a few workarounds have to be done to achieve the "Today" functionality. See steps below to create a "rolling" calendar view that shows calendar entries for X number of months out.

FYI, MS has on their site a list of some advanced filter options that I would recommend if your looking to do filtering, check it out, it helped me a lot http://office.microsoft.com/en-us/sharepointtechnology/HA011609471033.aspx

 

  1. Go to your Calendar list and create a column named "Today" and select "single line of text" and do not add it to the default view. This column is merely a placeholder column to achieve "Today" functionality that we can use to filter views
  2. Create a new column named "RollingDateFilter", make it a "calculated column"
    1. Set the calculated formula to "=AND(MONTH([Start Time])>=MONTH(Today),MONTH([Start Time])<=MONTH(Today)+2)"
      1. This formula will be used to filter our list
      2. If you want to see more months out, change 2 in the formula above to the # of months you want to see.
    2. Be sure to set the data type returned to "Yes/No"
    3. Be sure to uncheck "add to default view"
    4. IF you need to change the formula later, you will first have to recreate the "Today" column in step 1, modify the formula, save the formula, then delete the "Today" column.
  3. Delete the "Today" column
    1. This is needed for the "Today" value to be properly parsed in the above formula
    2. IF the "Today" column is not deleted, the formula using "Today" WILL NOT PROCESS CORRECTLY
  4. Create a new View and base it off the "All Events" view
    1. Select the columns you want to show, just accept the defaults
    2. Scroll down to the Filter section
    3. Set the filter to "RollingDateFilter" and set "is equal to" and set "Yes"
    4. Save the view
    5. You should now have a view that only shows 2 months out.
  5. Go to the homepage that has your un-filtered calendar view

     

    1. Edit the webpart
    2. Switch the view to "2MonthRolling" and save the changes
    3.  

The results below


Posted in: Sharepoint  Tags: , ,
Tony Testa posted on March 4, 2009 18:30

I guess I can say that I was blessed and cursed all at the same time when it comes to work.  I was luck enough to be a consultant working on billable projects up until now, and not just 1 project but typically 2-3 at a time.  Finally it looks like I have a few weeks here to be only on 1 project and one that is easy and something I can tap on old resources and knowledge I've accumulated over the years.  That being said it means I now have a bunch of backlogged blog postings that i’ve been meaning to put up for everyone to hopefully save someone some headaches.

Upcoming postings:

  • Fix for errors that SharePoint throws regarding SharePoint’s licensed being “expired”
  • Ideas for how to programmatically create sites and assign permissions and issues related with the process
  • Workflow emails not being sent; what to look for, what to make sure is there in the first place
  • Using PSTOOLS to make managing a SharePoint farm easier
  • How to parse SharePoint IIS logs
  • Basic SharePoint troubleshooting techniques
  • SharePoint “terms of use” page
  • SharePoint Dev. tools you should be already using
  • SharePoint Web Service Gotchas
  • Why NOT to use server names when dealing with SharePoint
  • HowTo: Silverlight and SharePoint integration: Basic steps to get started
  • Programmatically set Search results page

 

Obviously from the list above I have a lot I’ve promised and a lot of live up to but I can assure you these have all been in the works for awhile so 90% of the work is done.  More to come…


Posted in: Sharepoint  Tags: , ,

Today while helping a colleague with a SharePoint solution I remembered about URL tokens that SharePoint can use.  I swore for the life of me that I had blogged about them but apparently I didn’t.  On that note…here it is.

To get straight to the point, SharePoint has certain URL tokens that it will read from a URL and in its processing, translate into the actual values.  According to the article on How to: Add Actions to the User Interface, the following tokens exist:

Windows SharePoint Services supports the following tokens with which to start a relative URL:

~site - Web site (SPWeb) relative link.

~sitecollection - site collection (SPSite) relative link.

In addition, you can use the following tokens within a URL:

{ItemId} - Integer ID that represents the item within a list.

{ItemUrl} - URL of the item being acted upon. Only work for documents in libraries. [Not functional in Beta 2]

{ListId} - GUID that represents the list.

{SiteUrl} - URL of the Web site (SPWeb).

{RecurrenceId} - Recurrence index. This token is not supported for use in the context menus of list items.

If you search the web for “SharePoint URL Tokens” you’ll find the same copied list.  The one thing that you won’t find most likely is the following article by Stefan Gobner, Stefan Gobners URL Tokens Posting.  Stefan is a MS Support Engineer which means that he works through these weird issues on a daily basis and he blogged about a few extra URL tokens/Querystring parameters that shouldn’t be used in your URLs.  According to Stefan, the following parameter names shouldn’t be used:

  • FeatureId
  • ListTemplate
  • List
  • ID
  • VersionNo
  • ContentTypeId
  • RootFolder
  • View
  • FolderCTID
  • Mode
  • Type

Luckily none of these stumped me in the past but certainly a few times I recall naming some “random” query string parameters and knowing that these “shouldn’t” be used would have been helpful.

(03/06/2009 UPDATE) A colleague of mine just mentioned I should add:

  • k

Reason for not using k is because the search queries use that.  I am going to navigate a sharepoint site in my sparetime and look for additional ones as well because I know search uses a few more as well.


Recently a colleague of mine was dealing with a client whom he had been building an FBA site for.  All was fine and dandy until it came time to deploy the FBA site to the clients production WSS v3 server.  It turns out, which was completely news to me, that WSS v3 during the installation allows Active Directory Account Creation Mode to be enabled in the advanced settings.  I lended a hand and as you'll see why below, I immediately regretted the decision.

Ok you say, that's nice, WSS v3 allows that setting but the bad news is that apparently ADAM and FBA do not play nice together.  When WSS v3 is installed with the ADAM setting enabled, it makes the assumption that account names are in the form "domain\username".  Now anyone that has dealt with FBA knows that FBA account names are in the form "membershipProvider:accountname", so you can immediately see the problem.

ADAM and FBA just won't work together as it turns out, so after some digging, a BA I work with ran across the following link (http://office.microsoft.com/download/afile.aspx?AssetID=AM102157711033).  The link is to a document which details best practices for setting up WSS v3 in a Shared Hosting Solution.  Page 13, section 3.1.1 details Account Creation Mode, as well as page 16, section 4.1.1 details its shortcomings.  Page 23, section 5.1.1 details how ADAM and FBA just won't play nice together.  The key section in the document is 4.1.1.  That section states that MS recommends that you move off of ADAM at your earliest convenience, as well as stating that its a deprecated feature in WSS v3 and really shouldn't be used.  The document also states that ADAM is a security risk but doesn't really state why.  I also found (http://objectmix.com/sharepoint/337244-questions-regarding-ad-account-creation-mode.html), I believe it was Mike Walsh (a WSS MVP) stated that the next release of WSS will not support ADAM, that alone should prove why not to use it.  One final shortcoming I was able to dig up was that MOSS 2007 doesn't support ADAM, which should be another indicator to you why not to use ADAM.

Alright, all the above being said, we needed to let the client know exactly what security issues there were with having ADAM enabled.   Below is what I received back from a source at Microsoft:

  • When we use Active Directory account creation mode ,We have to use command line tool for creation of sites and other admin related tasks.
  • Limited user creation capability.
  • Users cannot be created in different OUs.
  • When we use Active Directory account creation mode, we cannot use pre-existing domain accounts; instead, new accounts are created whenever we add users.
  • Creating users and cross-site groups with Active Directory account creation mode is the same as creating users with domain account mode, except that we only enter the e-mail address or group name, not a domain account, when adding the user or cross-site group to a site. Windows SharePoint Services checks Active Directory to see if an account with that e-mail address or group name already exists. If the user or cross-site group already has an account in Active Directory, the account is used. If the user or cross-site group is new, an account is created for them in Active Directory, using the Windows SharePoint Services credentials, and they are notified of their account name and password through e-mail. This is very risky.
  • When we are in Active Directory account creation mode, there are certain administrative tasks that are unavailable in the HTML Administration pages. For example, we cannot create a top-level Web site, we cannot enable Self-Service Site Creation, and we cannot add a user to a site from the Central Administration pages. To perform these actions in Active Directory account creation mode, we must use the command line or the object model.
  • When we create a new account with Active Directory account creation mode ,The Minimum Password Age group policy on the domain controller must be set to 0 days. Failure to do so will result in users being unable to change their passwords, unless they have administrator rights on the server.
  • The ADAM authentication mechanism uses accounts defined within its own data store, Windows accounts valid on a system on which an ADAM instance instance resides, or it can redirect authentication request to Active Directory or Windows NT domains. In the latter case, the link to the Active Directory account is based on having its SID value stored in an ADAM user Proxy object. Redirection via proxy not only provides a single sign-on, but also enables storage of application-specific data for an Active Directory user outside of the Active Directory database, which is very problematic.
  • No administrator friendly account management Directory Services tool (equivalent to Active Directory Users and Computers) is currently available for ADAM installations. SO administrators will have to resort to more challenging methods to populate and manage directory information.

This basically answered well enough for me the security issues revolving around using ADAM.

Below are also some good links that may come in handy for you as well if you run into the issue.

http://objectmix.com/sharepoint/337244-questions-regarding-ad-account-creation-mode.html

http://microsoft.apress.com/feature/79/using-active-directory-application-mode-in-web-applications

http://office.microsoft.com/en-us/winsharepointadmin/HA011608091033.aspx

 

Long story short, ADAM is deprecated in WSS v3 and will not be support in the next version, ADAM and FBA don't play nice so move off of it ASAP to avoid issues for  yourself in the future.  If your working with MOSS, then you need not worry since ADAM isn't even an install option, so no chance of accidentally turning it on.

 

Originally we stumbled upon this problem when doing a site collection backup to the WSS v3.  The GUI threw us an error so we tried STSADM but still no luck.  The following links provied useful:

http://technet.microsoft.com/en-us/library/cc288330(TechNet.10).aspx

http://www.unikaconsulting.com/Lists/Technical%20Articles/DispForm.aspx?ID=1

http://www.sharepointblogs.com/essa/default.aspx

http://kbalertz.com/823507/determine-whether-Windows-SharePoint-Services-Active-Directory-account-creation.aspx


Posted in: Sharepoint  Tags: , ,
Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2017 Tony Testa's World