Showing posts with label WSS 3.0. Show all posts
Showing posts with label WSS 3.0. Show all posts

18 February, 2013

Disabled accounts in AD show up in SharePoint as active profiles

Problem Description:
If the proper filer is not applied in import connections then it can lead to hundreds of unwanted / disabled profile in ssp database. Sometimes due to IT audits we want to get rid of those profiles from SharePoint.

Product Applies:
1.    MOSS2007 (Microsoft Office SharePoint Server 2007)
2.    WSS3.0 Windows SharePoint Services 3.0)

Error Message: N/A

What exactly I did? How exactly I configured and came to know about the issue?
1.    In AD, I have created lots of user and disabled few of them.

2.    Configured SSP to import user profile by using the default filter
(&(objectCategory=person)(objectClass=user).

3.    That’s it-Problem started and found lots of profiles in view user profile.

Resolution:
·         At first apply filter (&(objectCategory=person)(objectClass=user)(
!(userAccountControl:1.2.840.113556.1.4.803:=2))) to just import active profiles in
connection.

·         Run full profile import three times back to back.

·         After that you will find users in view user profile > Profile Missing from import.

·         You can manually delete these unwanted profile or wait till clean up job delete them.

If you have any queries/questions regarding the above mentioned information then please let me know, Thank you.

14 September, 2012

10 Reasons Not to Brand SharePoint


  • Branding public-facing SharePoint sites considered mandatory
  • Custom user interfaces (UIs) require custom training
  • Invest in a governance plan, governance team
It seems that one of the first things people want to do with a new Microsoft SharePoint installation is to brand it. Branding public-facing SharePoint sites is considered practically mandatory. 

Branding internal corporate portals to reinforce the company image might also make sense. But the most common use of SharePoint within an organization is for departmental sites, team-collaboration sites, and document-management sites. Should you brand these internal sites?

There are two kinds of SharePoint branding for internal sites. One preserves the full SharePoint UI and feature set. This type of simple branding modifies graphics, colors, and font types. It uses features that are built in to SharePoint to let site owners update site navigation and Web Parts.

This branding might involve changes to Cascading Style Sheets (CSS) or edits to the SharePoint master pages, but it leaves the UI completely predictable to the average SharePoint user and can be supported without help from an outside branding expert or the person or department that performed the branding.

Anything more complex than this falls into the second category of branding. This type of branding often involves an outside branding consultant and hours upon hours of planning, design, and implementation to match the external company website or an older, custom internal site. This type of branding changes how SharePoint and its UI work.

Before you decide to brand internal sites by using this second category of customizations, ask yourself the following 10 questions. (If you still insist on branding your SharePoint installation after reading this article, see the sidebar "If You Must Brand SharePoint.")

#1: Would you pay to brand Windows Explorer or Microsoft Excel?
Have you branded your word processor or your email client? Of course not! These are tools. They should have a consistent and predictable UI, such as an obvious start button. After learning how to use a tool one time, you should be able to figure how to use the same kind of tool the next time. 

SharePoint is also a tool, especially when used for team collaboration and document management. Branding sites that are used for those purposes-especially when users might access more than one site-should be treated as such.

#2: Do you want to increase your per-user costs?
The per-user cost of a SharePoint installation is fairly reasonable. That is, until you start spending $10,000 to $30,000 per department-or even per site-to pay for a graphics design firm or branding consultant to customize your internal sites. The real-world branding costs can easily be in the hundreds of dollars per user and provide only a cosmetic benefit.

#3: How fast do you want users to get to work?
Customizing UIs takes time and often delays the start of a new SharePoint installation. Then, when branding has been approved, teams are put together to get the sites branded. 

These teams must interview consultants, review designs, wait for delivery, and test the result before the sites can be deployed to users. And then, if each site looks different, with a different and unpredictable UI, users will be wasting time figuring out how to navigate the site and how to find content.

#4: How much do you want to spend on training?
Out of the box, SharePoint has a wealth of available training and support resources, including instructor-led classes, books, online videos, and endless web resources.

All these resources are affordable (or even free) but are useful only for uncustomized sites. Custom UIs require custom training; without it, users are less productive.

#5: How much do you want to spend on support?
If each site is different, will your support groups be able to help your site users? Will your Help desk be able to answer questions such as, "In the HR site, I click on a green duck to get to the employee manuals, but I just went to the IT site to find software manuals, and there's no green duck. There are just two trucks, a race car, and a go-cart. Which should I click?" 

(If you think the duck-and-cars example is ridiculous, I'm not just being silly. I've seen many branded SharePoint sites that can be described only as "unique" and can be explored only by clicking everything you see until you find what you're looking for. You've probably seen sites like these, too-although, to be fair, site owners are sometimes the ones who insist on these odd designs.)

This brings up a related issue: Graphic designers aren't always good SharePoint designers. Graphic designers tend to think of SharePoint as just another custom website and often break or remove the most basic features, such as Quick Launch or the ability to add or change a Web Part. 

After the consultant, designer, or brander has finished with the site, who will pay for fixing such issues, or even updating the site later? If you want to add just one more link to their custom-designed navigation, will you need to pay to redesign the site?

#6: How much time do you want to waste?
Of course, much too often, the site owner is the one doing the branding. SharePoint Designer is free, easy to download, and talked about everywhere on the web. And it's so easy to use that site owners often become self-taught site web designers, spending much of their time playing with SharePoint Designer. 

This problem isn't new. Remember the early spreadsheet days, when managers switched from managing teams to spending all day playing with spreadsheets? Now, in the age of SharePoint, we have managers and team leaders spending too much time as web designers. Most of these site owners have no design training and no governance.

#7: Do you know who's in charge?
When every department is doing its own thing with SharePoint, is any department doing the right thing with corporate assets? Are site owners following corporate standards for site content and content governance, or are they simply creating cool-looking sites with random links and storage? 

If you lose control of SharePoint and the content that's stored there, you might never get it back (short of starting over from scratch). And when the legal or R&D departments ask, "Can you find X?" or "Can you tell me who did Y?" are your SharePoint sites organized and structured enough to actually perform an audit?

#8: How difficult will sites be to audit?
If each department and team feels free to create custom UIs as a means of branding, then they also might feel free to store their content any way they like. If they have their own branding, then they will surely have their own custom content types, list types, and metadata.

How will a researcher or auditor find anything in such a system? Imagine being an auditor who must visit a hundred sites, each with a different UI, to find a document about a customer or a product. This Wild West approach is expensive and difficult to maintain.

#9: Are there better places to invest your money?
How much sense does it make to try to reduce costs by licensing SharePoint Foundation or SharePoint Server Standard Edition, only to spend a lot of money on custom (and cosmetic) branding, and then more money on custom training and lost productivity because of the branding? For the same price, you can stay with out-of-the-box SharePoint and spend the extra money on SharePoint Enterprise Edition, Microsoft FAST Search Server, and some powerful business intelligence (BI) tools. 

You might even have enough to invest in faster hardware, the next level of SharePoint, or more user training. If you're interested in doing things the right way, right from the start, then invest in a governance plan and an ongoing governance team.

#10: Do you really want to do this all over again?
Your branding costs don't end with the current installation of SharePoint. Sooner or later, along comes the next generation of SharePoint with a whole shopping cart full of new features that you want and need. 

Branded sites almost never upgrade cleanly. Over the past few years, I've seen how the migration from SharePoint 2003 to SharePoint 2007-and more recently from SharePoint 2007 to SharePoint 2010-has worked for branded sites. 

Typically, it hasn't been a good experience and has required paying branders to rebrand all the sites to work in the new version. Are you willing to bet on the effort and cost of moving your branded sites to the next version of SharePoint?

The Bottom Line
Before you make the decision to brand internal sites, make sure you have a real business need to do so. Remember, SharePoint is a tool, like Microsoft Word or Excel. You don't brand those programs, do you? 

Talk to other companies that use SharePoint, and find out what it's really costing them to brand sites, including the ongoing costs to support branded sites. Will new hires be able to figure out all the custom UIs and site designs? Will you need to upgrade customized sites to a new version of SharePoint (or even to another product)? 

Look at your budget. Can you afford the up-front costs, ongoing support costs, end-user training costs, and eventual upgrade costs of branding? 

And what about legal and business accessibility requirements (e.g., support for screen readers, high-contrast text, nonmouse navigation, Web Content Accessibility Guidelines--WCAG-2.0). How might branding affect these requirements? 

In a nutshell, do you really need to brand?


11 September, 2012

Web Services Uncovered: SharePoint 2007.


Today we are going to talk about the Web services in SharePoint. We all know SharePoint provide very extensive support for the web services, writing custom web services, we will try to compile some information on this. 

What is a web Service?

A Web service is a method of communication between two electronic devices over the Web (Internet).

The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network". It has an interface described in a machine-processable format (specifically Web Services Description Language, known by the acronym WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

What is SOAP? 
SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on Extensible Markup Language (XML) for its message format, and usually relies on other Application Layer protocols, most notably Hypertext Transfer Protocol (HTTP) and Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.

Web services protocol stack?

A web service protocol stack is a protocol stack (a stack of computer networking protocols) that is used to define, locate, implement, and make Web services interact with each other. A Web service protocol stack typically stacks four protocols:
  • (Service) Transport Protocol: responsible for transporting messages between network applications and includes protocols such as HTTP, SMTP, FTP, as well as the more recent Blocks Extensible Exchange Protocol (BEEP).
  • (XML) Messaging Protocol: responsible for encoding messages in a common XML format so that they can be understood at either end of a network connection. Currently, this area includes such protocols as XML-RPC, WS-Addressing, and SOAP.
  • (Service) Description Protocol: used for describing the public interface to a specific Web service. The WSDL interface format is typically used for this purpose.
  • (Service) Discovery Protocol: centralizes services into a common registry such that network Web services can publish their location and description, and makes it easy to discover what services are available on the network.
Web Services in SharePoint?

The web service .asmx files are located at "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI"
Every SharePoint Site has a virtual directory known as "_vti_bin" which maps to the above directory.  Don't believe me?  Open up your IIS management console, go to one of your web apps, and look where "_vti_bin" maps to in the file system.

Here is a list of the web services:
Name
URL
http://<AdminSite>/_vti_adm/Admin.asmx
http://<Site>/_vti_bin/Alerts.asmx
http://<Site>/_vti_bin/Authentication.asmx
http://<Site>/_vti_bin/Copy.asmx
http://<Site>/_vti_bin/Dws.asmx
http://<Site>/_vti_bin/Forms.asmx
http://<Site>/_vti_bin/Imaging.asmx
http://<Site>/_vti_bin/DspSts.asmx
http://<Site>/_vti_bin/Lists.asmx
http://<Site>/_vti_bin/Meetings.asmx
http://<Site>/_vti_bin/People.asmx
http://<Site>/_vti_bin/Permissions.asmx
(in stssoap.dll)
http://<Site>/_vti_bin/SiteData.asmx
http://<Site>/_vti_bin/Sites.asmx
http://<Site>/_vti_bin/spsearch.asmx
http://<Site>/_vti_bin/usergroup.asmx
http://<Site>/_vti_bin/Versions.asmx
http://<Site>/_vti_bin/Views.asmx
http://<Site>/_vti_bin/WebPartPages.asmx
http://<Site>/_vti_bin/Webs.asmx

SharePoint has a rich list of Web Services it support so it is always good to keep handy the SharePoint Web Services Link provided by Microsoft, http://msdn.microsoft.com/en-us/library/ms445292.aspx
 
A nice reference to the well explained Architecture of Web services by Trent Swanson: http://www.infoq.com/articles/swanson-moss-web-services.
You nice video on calling web services  using silver light application: http://www.youtube.com/watch?v=_-Z30-1sdXY

If you have any queries/questions regarding the above mentioned information then please let me know. Thank you.