You read a few postings on how to connect MOSS to oracle database, and you concluded that the installation and configuration of oracle client should take less than 30 minutes; After you search for oracle driver, registered at Oracle site to download “appropriate” driver, after a few dry runs, you realized oracle client driver installation which was supposed to take only 30 minutes is now running into a couple of hours; If you are caught in this merry-go round, the following steps are for you…

1. Download ODAC10202.exe or ODTwithODAC10202.exe into a temporary folder. Please note: Do not download this file into the “Tmp” directory.

2. Unzip its contents by running the executable.

3. In the directory where you unzip ODAC10202.exe, an install directory is created.

4. Run the Oracle Universal Installer (OUI) by launching the setup.exe within the “install” directory that was unzipped.

4. OUI will lead you through the installation on your machine. After the installation, you may delete ODAC10202.exe and the temporary installation folders and files.

5. A Net service name allows an Oracle client to use a simple alias to connect to the database server. The alias definition contains all the information needed to create a connection.

6. To create an alias, launch Net Configuration Assistant from Windows Start Menu –> All Programs –> Oracle – <Oracle Home> –> Configuration and Migration Tools. Follow these instructions to create a net service name as a shortcut for the data source value in your connection string.

7. To avoid any error, copy the tnsnames in UAT and place it under <%Install Directory%>:\Oracle\product\10.2.0\client_2\NETWORK\ADMIN

Please see the screens below for OUI Step by step screen. And test your connectivity to the oracle database. First, use the famous PING to verify physical layer connectivity to the Oracle database. Then use tnsping to verify connectivity to Oracle database

Note: On the screen below, select the first option.

Note: In Step 7, the path in textbox two below is the Oracle path. Look for the ADMIN directory in the path and place your tnsnames.Ora file.

Note: Verify that all these options below are selected

Sample tnsname.ora file…..

TTTUAT_HOSTNAME.TT.COM=

(DESCRIPTION=

(ADDRESS=

(PROTOCOL=TCP)

(HOST=167.32.54.20)

(PORT=1566)

)

(CONNECT_DATA=

(SERVER=dedicated)

(SID=TTUAT)

)

1. People Picker will only allow you to select users from the same domain in which MOSS is installed – this is by design in MOSS

2. To provide visibility to users who exist in domain other than the one in which MOSS is installed, you need to add entries to MOSS specifying the other domain(s)

3. There two issues that must be considered -

1. If the domain in which MOSS is installed has a two-way trust, then you can provide those entries and the application pool account must be granted permission to access the other domain. The stsadm syntax for this settings is STSADM.exe -o setproperty -pn peoplepicker –searchadforests” The argument you provide must include the dns name of the forest. You must include forest as the first word. If your forest name is mycompany.local, then a valid argument will be forest:MyCompany.local. If you have a second forest to include, you must separate the first and second forest with a semi-colon. Example forest:MyCompany.local;My2ndCompany.local where My2ndCompany is a valid dns name of your second forest
   

    

   The full argument will be …
   

   STSADM.exe -o setproperty -pn peoplepicker –searchadforests –pv “forest:MyCompany.local;My2ndCompany.local”
   

1. If the domain only has a one-way trust, you use the same stsadm syntax as above, but because this is a one way trust, you must specify the username and password needed to authenticate to the forest/domain. Using the same example above, your syntax and argument will be as follows:
   

    

   STSADM.exe -o setproperty -pn peoplepicker –searchadforests –pv “forest:MyCompany.local, MyCompany/mark,Password;My2ndCompany.local My2NDCompany/Matthew,Password”
   

To get a firm grasp of ASP.NET identify matrix, visit Microsoft Web Site at http://msdn.microsoft.com/en-us/library/aa302377.aspx

After the first initial full deployment, always perform incremental deployments. Otherwise, you end up with a destination site that is out of synch. A delete scenario is a good example of where multiple full deployments can result into inconsistent environment.

Destination must be a blank site, at least for the first full deployment; Incremental deployment does not need to go to a blank site. The idea of incremental backup presumes there is a full backup already at the destination sited. Note that content deployment does not address the deployment of Features, assemblies, or configuration. Where content depends on assemblies containing web parts, custom fields or field controls – or other file system, it is best practice to deploy these other components close to the time of deployment. Whenever you deploy to a blank site, the publishing infrastructure is activated. If you have a feature installed on a destination site but not activated. Same feature which was already activated at the time of packing the content at the source will be activated as part of content deployment after the content has been unpacked and deployed at the destination server.

Security: You can specify an alternate account, or you can use the application pool account for the central administration site. If you are using either account, ensure that the account has access to the destination site.

You can use quick deploy to get your content published immediately if you don’t want to wait for the time that a scheduled job will run. But this quick deploy is only available to site owners. However, if you have Sharepoint publishing infrastructure Feature enabled, then users who belong to the quick deploy group will have a button that allow them to deploy quickly on the site

Note: If there is an enterprise standard that requires all shared artifacts to remain in the layout directory, you can develop a feature to copy this value from the layout directory to a location within the site collection. I will provide a sample of how to do this in another posting

After you restore your site collection, MOSS may need to reset how it points to pages. To correct this issue, you need to run two commands. The first is an stsadm deletecontentdb – this command is misleading because it does not delete your contentdb. Once you run this command, then run the addcontentdb to restore the links.

Here are the commands

Stsadm -o deletecontentdb -url [URL of your site collection] -databasename [Name of Your Content DB]

Stsadm -o addcontentdb -url [URL of your site collection] -databasename [Name of Your Content DB]

After you complete the two steps above, verify all the assemblies referenced in your code are available in the assembly GAC. These two addressed this issue. I hope it will help someone struggling with this weird error message.

** About the Author: Anthony Odole is a Senior Solution Architect with IBM Global Services. He is a SharePoint Subject Matter Expert. You can reach him at Odolea@gmail.com

To further ensure that user’s security in one site collection does not affect the settings in another, SharePoint treats each site collection as an island. Understanding SharePoint internal security workings is very important when you call runWithElevatedPrivilege delegate in your code. This understanding is critical to knowing which account is used to either an internal securable object, or external resources. So, let’s dig into details of the internal workings of SharePoint.

Authenticated User and Identity of current thread: For a normal process, the identity of the current thread is the identity of the current user. Interestingly enough, there are two identities at play. The first is the windows identity, and the second one is the WSS identity. That these identities are same until you need to run in an elevated privilege mode is the cause of most confusion for developers.

Authenticated User and RunWithElevatedPrivilege Delegate: Before calling RunWithElevatedPrivilege delegate in your code, the SharePoint (WSS) and Windows Identities of an authenticated user are the same. After you call RunWithElevatedPrivilege delegate, two things happen:

1. The windows identity changes and impersonates the application pool account
   

    

2. The SharePoint (WSS) identity changes and impersonates SharePoint system account (SharePoint\System) – this is an internal SharePoint account with a pervasive privilege to access and manipulate all security objects in SharePoint environment.
   

So, it is important to understand that you have total control and permission on any object within SharePoint when you call this delegate. You should also understand that you are impersonating the account of the application pool if you need to access resources external to SharePoint environment.

Shared Proxy Objects: From the discussion above, it is important to note that your identity is established when you create a shared proxy object. Compare the following two scenarios below

Scenario 1: You create your shared proxy object, then call RunWithElevatedPrivilege delegate.

Scenario 2: You call RunWithElevatedPrivilege, and then create your shared SharedProxy Object.

There is a common confusion around these two scenarios. In the first scenario, you notice that your thread still does not have access to the SharePoint securable objects and that you are unable to manipulate these objects even when you assumed you are running in elevated privilege mode; when you check thread identity, you notice that it is running under the Identity of the authenticated user. For the second scenario, however, things worked as expected, i.e., your code is able to manipulate SharePoint securable object. The identity of a shared proxy objects such as SPSite is established when you create an instance of that object. So, you if get current context, then try to run with elevated privilege, you are inadvertently running in the context of the authenticated user instead of the system account. You only run in the context of SharePoint\System account if you first call enter elevated privilege mode before you create the shared proxy object.

Web Part: How do all these affect web part deployed on SharePoint? Well, Web Parts or other custom applications does not execute under the worker process identity (application pool identity). Two things happens when a web part runs within the context of a SharePoint Portal – for a user authenticated against active directory, WSS switches the thread context to the windows identity, and for a user who is not authenticated against active directory, WSS switches the security to that of the machine account, which by default is IUSR_MachineName. The second scenario is what happens when your users are not authenticated against active directory, for example, when you use Form Based Authentication. You can configure the impersonation of IUSR_MachineName in the Web.Config file.

These subtle differences are very critical to your developing a secured SharePoint solution, and even more critical if you have multiple authentication providers in your environment.

** About the Author: Anthony Odole is a Senior Solution Architect with IBM Global Services. He is a SharePoint Subject Matter Expert. You can reach him at Odolea@gmail.com

When you resize your drive, you have an option to create a new one from the old copy, or to overwrite the old one with the new one; do not override the old one. Always create your new larger size from the old one while retaining the old one – because we need the old one in the steps below:

After resizing your new hard drive, attach the new virtual hard drive as a drive # 2 in your virtual machine and follow the steps below:

With the setting as specified above, boot into your OS using your old smaller drive as boot drive. Log in, and then bring up command prompt. Go to the root. Then type DiskPart. This command starts diskpart tool that is available in Windows 2003

Of course, it will stop at DISKPART> Then type List Volume. This command lists all the volumes.

Note: After I ran this command, I got the screen below. The C drive is my old drive with a size of 4989MB, but after resizing to 20Gig, I attached it as a second drive on my virtual machine as E drive. Notice that it is still showing in Windows as 4989. This is the same size that it shows in windows explorer. But if I right click to get the properties of the drive like any other file in windows, the property shows that it is 20Gig. And you will notice that the file actually took 20Gig on your host hard drive – just that it is not showing and not available in windows yet.

Very important note: Before you proceed, you need to look at the information returned when you first run list volume command. Look at size, it will be the same – otherwise, there is no need to proceed; Check status, it must show healthy – and this is usually the case; now, check the list column called Info. Verify that your new hard drive does not show System or Boot, that is, make sure only your old hard drive is showing boot or system.

If, as in my case above, you notice that your newly resized hard drive on drive E shows under the Info column anything other than blank, then you have one additional step to take before you proceed. Additional step: Shutdown your virtual PC.
Change the newly resized hard drive from the second place to the third place. If you previously have it as drive # 3 on your virtual PC configuration, you should change it to too.

Then run repeat the steps – disk part, list volume. If there is nothing under Info Column for your new hard drive, then you are ready to proceed to the next steps.

Now, the next step is to set FOCUS on Volume 2 with letter E. To do this, type the following on the DisKPart Prompt…

Now you have selected Volume 2 and it is by default given a drive letter E. Note: the letter assigned to your new drive may be different.

Now that it is selected, you need to assign a new drive letter. It is very important that you change the drive letter. See the screen below for the command to type.

Now just to verify that now it has the new drive letter by issuing the list Volume command – just to verify.

So far so good: you have verified that that Info column for your new hard drive does NOT show system or boot; you have changed assigned a new drive letter. Now, you need to extend the size, so that windows can see the new size. See the command below. Please, note that the drive specified should be the amount of free spaced, i.e., your new drive size minus your old drive size should give you an idea. Issue the extend size=????, see the example below.

Of course, if you try to extend far more than you have, you will get an error message.

Follow the steps above exactly and in the sequence outlined. Many developers, who created too smaller a drive size or who ran out of space on their existing drive, usually follow the instruction on how to resize until they realize that windows does not see their new drive size. Then they follow the instruction on how to resize until they get frustrated because disk part is providing error s such as “The volume you have selected may not be extended”

** About the Author: Anthony Odole is a Senior Solution Architect with IBM Global Services. He is a SharePoint Subject Matter Expert. You can reach him at Odolea@gmail.com

How to Create an SSP:

Step 1: Go to the Shared Services Administration page.

Step 2: In this case, we are creating two web applications – one for MySite and the other Shared Services Provider. Note that by default, the two are created under the same web application. I’ll recommend you use separate application pools.

1. Create a new account for Shared Services Application Pool
   

   
   

2 b. Create web application for Shared Services Provider

1. C. Now that an application has been created for SSP1, select this application for Shared Services and then create another web application for MySite. Create an account for the application pool that you plan to use for MySite Web Application
   

   
   

So, now you have two web applications – one for Shared Services, and the other for MySite; let’s create a third account for Shared Services Credentials

With two web applications, and the account for shared services credentials, we are ready to create Shared Services Provider:

Ok, if everything works as expected, you should have the screen below showing all shared services configured successfully

Before we reconfigure the MySite location, we need to enable self-service creation. Without enabling self service, clicking on my site will generate the following error message: “Your personal site cannot be created because Self-Service Site Creation is not enabled. Contact your site administrator for more information “

It is important to also note that you cannot configure site creation if there is no site collection at the root of the web application. Enabling site creation without a site collection at the root will generate the following error message: “Cannot enable site creation because there is no site collection at “/” on the Web application.“

So, to turn on Self-service creation, you need to follow these steps:

1. Click Start, point to All Programs, point to Administrative Tools, and then click SharePoint 3.0 Central Administration.

2. On the Central Administration home page, on the top navigation bar, click the Application Management tab.

3. On the Application Management page, under the Application Security section, click the Self-service site management link.

4. On the Self-Service Site Management page, select the web application for mysite from the Web Application drop-down list,

5. Select “On” option

Here is the issue: The default site is located at http://yourDomain, but MySite is located at http://yourDomain:5552/personal/<unserName>/default.aspx. The preferred deployment scenario is where users will browse your main site with http://yourDomain, and browse mysite using http://yourDomain/personal/<unserName>/default.aspx. Notice there is no port number in the url for MySite.

To address this issue, you need to follow the steps below:

Step 1: Go to the main application, that is the http://yourDomain application, create two managed path: one Explicit inclusion for path “MySite”; the second one a wildcard inclusion for path “personal”

Step 2: Create a new site collection using the MySite Host template. Now you should have the correct URL.

** About the Author: Anthony Odole is a Senior Solution Architect with IBM Global Services. He is a SharePoint Subject Matter Expert. You can reach him at Odolea@gmail.com

When we go to properties of any document in document library even with full permission, we get access denied message if we try to edit the document properties. However we can open and edit the document successfully.

This is one of those errors that you spend a lot of time troubleshooting without a clue of why this is happening. As an experienced MOSS developer, you probably assume this is a permission issue; With this assumption, you use farm administrator account to log into the site, still you get access denied error page. You tried so many other steps, all to no avail. There is a good news and a bad news. Which one will you like me to talk about first? Just kidding!

Ok. The Good news is that you did not create or cause this issue. The bad news is that it is a bug. I’ve called and discussed this with the folks at Microsoft. There are two ways to fix this. Use step 1 to fix this issue in existing document libraries. Use step 2 to fix it in existing list templates

Step 1. For existing lists, you can run the following code to fix it. This here is a sample peace of code that should add the appropriate attribute to the list having the issue:

void FixField()

{

string RenderXMLPattenAttribute = “RenderXMLUsingPattern”

string weburl = “<http://localhost>”

string listName = “test2″

SPSite site = new SPSite(weburl);

SPWeb web = site.OpenWeb();

SPList list = web.Lists[listName];

SPField f = list.Fields.GetFieldByInternalName(“PermMask”);

string s = f.SchemaXml;

Console.WriteLine(“schemaXml before: ” + s);

XmlDocument xd = new XmlDocument();

xd.LoadXml(s);

XmlElement xe = xd.DocumentElement;

if (xe.Attributes[RenderXMLPattenAttribute] == null)

{

XmlAttribute attr = xd.CreateAttribute(RenderXMLPattenAttribute);

attr.Value = “TRUE”

xe.Attributes.Append(attr);

}

string strXml = xe.OuterXml;

Console.WriteLine(“schemaXml after: ” + strXml);

f.SchemaXml = strXml;

}

Step 2: For existing stp (list templates) that are having this problem, you should be able to modify the manifest.xml to add the attribute, and repackage the stp. You simply would rename the .stp file to a .cab file, open the manifest.xml file packaged in the cab, make this change that is highlighted:

<Field ID=”{BA3C27EE-4791-4867-8821-FF99000BAC98}”

Name=”PermMask”

SourceID=”http://schemas.microsoft.com/sharepoint/v3“

StaticName=”PermMask”

RenderXMLUsingPattern=”TRUE”

Group=”_Hidden”

ReadOnly=”TRUE”

Hidden=”TRUE”

ShowInFileDlg=”FALSE”

Type=”Computed”

DisplayName=”$Resources:core,Effective_Perm_Mask;”>

<FieldRefs>

<FieldRef ID=”{1d22ea11-1e32-424e-89ab-9fedbadb6ce1}” Name=”ID”/>

</FieldRefs>

<DisplayPattern>

<CurrentRights/>

</DisplayPattern>

</Field>

Then repackage the manifest.xml file to a .cab file and rename it back to .stp. Upload the list template to the template gallery. Any subsequent lists created with this template should work as expected.

Microsoft promised to fix this in the next hotfix. Please note that to prevent new list templates from having this problem, you will need to update the fieldswss.xml via the next Hotfix. Please do not update fieldswss.xml manually.

** About the Author: Anthony Odole is a Senior Solution Architect with IBM Global Services. He is a SharePoint Subject Matter Expert. You can reach him at Odolea@gmail.com