You are currently browsing the tag archive for the ‘tips’ tag.

A lot of times the MDX query needs to look at current date/today date/system date as the reference member. There is no function equivalent to TSQL getdate(), but you can use the following piece of cide snippet to solve the purpose:

StrToMember(“[Date].[Date].[” + Format(now(), “yyyyMMdd”) + “]”)

As an example, if you want to see the Sales for the last 7 days from the system date:

 [Measures].[Sales]  ON COLUMNS,
 LastPeriods(7,  StrToMember(“[Date].[Date].[” + Format(now(), “dd-MM-yyyy”) + “]”) )  ON ROWS
FROM [Cube]


Had my users complain about how painfully slow it is the first time they hit the portal every morning, and then things get back to normal. I had put it on the back-burner, but now that things are under control, I got some time to revisit this issue.

Every night, the App Pool recycles, and then pages are compiled from the generic MSIL to native code upon first use. This is known as just-in-time (JIT) compilation. If not performed beforehand, it can cause pages to load slower the first time they are requested.

This can be simulated by doing an iisreset on your server and benchmarking the time it takes to load a page… just for kicks

What I needed was a warmup script that would hit all critical webpages for me every night, after the recycle. Found this file that I customized to my use.

All credit goes to Joel Olson, and Andrew Connell

After playing around with my MOSS installation for some time, I realized that a lot of stuff resides in what Microsoft euphemistically calls the ’12 hive’. So, instead of pulling up the command prompt everytime and navigating to the directory, I decided to create a desktop shortcut.

  1. Go to the Desktop on the server that is running SharePoint Server 2007
  2. Right click and choose New -> Shortcut
  3. Type %windir%\system32\cmd.exe in the location textbox, click Next
  4. Name the shortcut as Shortcut to 12 Hive or anything else you want, click Finish
  5. You will see the icon for the shortcut you just created on the Desktop
  6. Right click the icon and choose Properties
  7. On the Shortcut tab, change the value in the Start in textbox to the location of the 12 hive,
    type “%PROGRAMFILES%\Common Files\Microsoft Shared\web server extensions\12\bin”
  8. Click OK.

Of course, the other way would be to have it in your PATH

Now now, not everybody has the latest version of Excel on their desktops. Does the mean they are SOL ? Not quite, there is a way you can use Excel 2003 as a client to ‘publish’ spreadsheets for use with Excel services.

Make sure you have the Office 2007 Compatibility Pack installed. You need this to be able to save your Excel file in Excel 2007 format.

I had promised to bring the features and review the same for the neat Sharepoint Deployment Tool on Codeplex

Ability to Pick and Choose content

Say you have finished developing and unit testing the code, and now it needs to be pushed into UAT. You might not want to export/import the whole site, as there might be pieces you are still working on. This tool comes in handy in such cases as you have the ability to pick and choose the items you want to deploy, down to the individual files, items, lists level. This is very useful when deploying/migrating content from one environment to the next.

Dependant objects can be selected

Any referenced objects, master pages, CSS files, images, etc are included by default as a part of the export and that greatly reduces the chances of something ‘breaking’ as a part of the deployment. You have the option of choosing ‘Exclude dependencies of selected objects’, of you so desire.

Retain Object GUID

If you have used stsadm, you might have noticed that there is no option to retain GUIDs when deploying sites. This makes troubleshooting and debugging a lot more difficult. This tool retains object GUIDs as a part of deployment. This helps in incremental deployment on sites that already exist on the target.

Versioning Flexibility

You have the choice of getting the latest major version, major and minor version, or all versions of any and all items you are looking to deploy. This helps make incremental changes possible for objects that need to go in on top of what already exists on the target.

And best of all, its FREE


Nothing is perfect, of course.

Some shortcomings

Does not work for the following types of content – recycle-bin, alerts, audit trail, change log history, workflow tasks/state.

Does not work for system level files – features, assemblies, solutions, etc

Cannot transfer list items to another at a different URL. Click here for a discussion on this.

Overall, even with the few limitations, it is a great tool and something you should check out and put in your toolbox. It will definitely come in handy.

Continuing my tussle with setting up Kerberos authentication in the sharepoint environment, I ran into another issue today.

Windows has a rule that causes it to fall back to NTLM authentication if there is an issue with the Kerberos authentication. So I had to validate that we were indeed using Kerberos as the authentication method, and in order to do that, I had to enable logon events on the servers.

To get to the Local Security Settings, go to Start -> Run (or just press <Windows Key>+R)
type secpol.msc
Navigate to Security Settings -> Local Policies -> Audit Policy

Local Security Policy Window

Local Security Policy Window

 The events you want to log are:

Account logon events: This event is audited to see each instance of a user logging on to or logging off from another computer in which this computer is used to validate the account. Account logon events are generated in the domain controller’s Security log when a domain user account is authenticated on a domain controller. These events are separate from Logon events, which are generated in the local Security log when a local user is authenticated on a local computer. Note: Account logoff events are not tracked on the domain controller.

Logon events: This event is audited to see when someone has logged on or off your computer (either while physically at your computer or by trying to log on over a network).

Double-click Audit account logon events to bring up the window to change Security Settings
I found that the Properties window had the Success and Failure options greyed out

Audit Logon Events Properties (Disabled)

Audit Logon Events Properties (Disabled)

 I was logged in as a Local Administrator, but it just wouldn’t let me enable those options.
Apparently, the Group Policy at the Domain Level takes precedence over Local Security Settings. And since I do not have Domain Administrator permissions, I could not login to the Domain Controller to make any changes.

The next step was to manually override the domain level Group Policy with the caveat that it will only last for 2 hrs as the domain controller refreshes the policies every 120-min.

Open Command Prompt: Start -> Run (or just press <Windows Key>+R)
type cmd
Change directory: cd C:\Windows\Security\Database

Export the existing security policy. This extracts all policies from the database and puts them in the Security Template file. Use the following command:
secedit /export /db SecurityDBName /cfg SecurityTemplateFile

Edit the Security Template file
notepad SecurityTemplateFile

Look for [AuditLogonEvents], change the value to 3 (for both Logon and Logoff to be audited)
Look for [AuditAccountLogon], change the value to 3 (for both Logon and Logoff to be audited)

Validate the Security template file thus created
secedit /validate SecurityTemplateFile

If everything checks out okay, make the changes to the security policy as:
secedit /configure /db SecurityDBName /cfg SecurityTemplateFile /overwrite

And you should be in business, with both options checked (though still greyed out)

Audit Logon Events Properties (Enabled)

Audit Logon Events Properties (Enabled)

Add to FacebookSlashDot ItAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

In order to do a MOSS (aka Sharepoint) 2007 install using best practices, Microsoft recommends creating and using service accounts.
Click here for Microsoft article

I will summarise the long article into more relevant details (and for futher reading, you can click the link above)
Following are the service accounts I created and the permission levels specified for MOSS to install and function properly.

1. MOSS Setup Account (MOSS_Setup)
Typically, this is the account used to do a MOSS/Sharepoint install and setup.
This account is used for a lot of tasks – MOSS installation, creating new IIS sites and SQL Server databases.
It must belong to the Local Administrators group. Also, this account must be a Domain User, have access to the SQL Server instance to be used, with securityadmin and dbcreator roles.

2. SQL Server Service Account (SQL_Svc)
This is the account used to install the SQL Server instance to be used for MOSS databases.
I have used the account to run the SQL Server Service & SQL Server Agent Service.
Can be setup as a Domain User with no elevated permissions.

3. MOSS Farm Account (MOSS_Farm_Svc)
This account is used by the MOSS Server to access the SQL Server databases, and should be used as the identity for the Central Administration application pool and the WSS Timer service.
This account can be setup as a Domain User, need not be a local admin.

4. MOSS Application Pool Process Account (MOSS_AppPool)
When each application pool is setup, you must specify an account that will be used for that specific application pool’s identity. This account will be used to access the content databases associated with the web application. It is recommended that a new service account is created for each application pool. This should be a Domain Account with no specific permissions. When the account is specified & SharePoint creates the application pool, it automatically grants the account additional needed permissions.

5. Shared Service Provider Account (MOSS_SSP1_Svc)
This account is used for the Shared Services Provider (SSP) Web Services & the SSP Timer jobs.
It should be a Domain User with no elevated permissions.
It is a good practice to name the account using a number, since each SSP can run under its own account. This also helps connect the SSP Accounts back to the related SSP.

6. Office SharePoint Server Search Account (MOSS_Search_Svc)
This is an account used by the Shared Service Provider to crawl local & remote content.
This account should be a Domain User, having Local Administrator permissions on each MOSS server.

7. Default Content Access Account (MOSS_SSP#_ContentAccess_Svc)
This is the account used if a specific account (see #8) is not specified for the content source being crawled, unless a different authentication method is specified by a crawl rule for a URL or URL pattern.
Specific for each individual SSP, this account should be a Domain User and must have read access to the content sources it needs to crawl.

8. Content Access Account (MOSS_Content_Svc) – Optional
This is a specific account, specified when you create a new crawl rule, and configured to access a content source.
For example, content sources that are external to Office SharePoint Server 2007 (such as a file share) might require a different access account.
Like #7 above, this account should be a Domain User and must have read access to the content sources it needs to crawl.

9. Windows SharePoint Services Search Account (WSS_Search_Svc) – Optional
The WSS Services Search is only used to provide search capabilities within the Help content.
This account should be a Domain User with default permissions.


July 2018
« Mar    

Blog Stats

  • 44,396 hits