Other Problems:

I am trying to build a WSS 3.0 site.

I am having difficulty with the dialog box that pops up when I try to check out a document. I tried to solve this by enabling forms based authentication but when I click on the document, Microsoft Word opens and I get garbage (MS Office also fails ).

All I want to accomplish is to log into my WSS 3.0 site from any computer and when I'm logged in, edit and upload documents without having the dialog box interrupt me.

How can this be accomplished?

'm running EV 9.0 SP2, archiving MOSS 2007 SP2. The documents get archived fine, but opening them is a problem.

When I try all kinds of different users, with explicit permissions to the archived file, including the most powerful Farm Admin user, I get the error message:

 

Error Opening Document

The Enterprise Vault Server is unavailable or access is denied.

The only user that allows me to access the archived file is the EV account.

There is nothing the Dtrace or IIS logs that I could find, only when enabling the EV logging in web.config I see the following error when EV fails to open files:

File content: EVSTUB

Requested document is a shortcut

Fetching item content from vault

** Error: msgSym = VaultUnavailable

** Error: msg = Exception from HRESULT: 0x80040303

** Error: exCode = -2147220733

Prerequest handler finished

I double checked all the prerequisites and name resolution of aliases, and I can't think of anything else.

 

We have a SharePoint 2010 site which is published externally using TMG 2010. The publishing rule on TMG is set to use HTML Forms Authentication and persistent cookies. I can log in to the site externally using Internet Explorer and open/edit any Office document without being prompted for a login. If I try and open a document or document library from within an Office app when not logged in via IE (i.e. no persistent cookie) I get prompted for a login, but it will not accept the details I enter.

 

If I look at the logs on the TMG server, I get several entries with the status "401 Unauthorized" when I try and open the document. I then get several more entries with the status "12202 Forefront TMG denied the specified Uniform Resource Locator (URL)" when I enter my login details. However, the same URLs are accessed when I open Office documents after logging in via IE and I don't get these errors then.

 

When I access Office documents on our SharePoint site from within our network, be via IE or Office, everything works fine.

 

Does anyone know how I can get documents to open directly from Office on the externally-published site?

Opening Files in Their Native Programs With SharePointWhen you click on a file in a SharePoint document library, it launches the file. Most often you'll be prompted as to what you want to do with the file (Open, Save, etc.). In some cases (like Office documents) it will open the file but the program that is doing the client side work on it, renders it in the browser. How many times have you clicked on a Word document and have it launch in the browser so you're looking at IE with an embedded Word control rendering your document. Half the time the user doesn't know what happened and when they close the browser the site is gone when really they wanted to hit the Back button to get back to their doclib. How frustrating.

Unfortunately the answer isn't an easy one, at least if you have a large deployment of users you need this to happen with. It involves setting up a property with the associated file. The setting is in the web browser, not SharePoint. The technique varies based on different environments (version of browser, version of OS, version of Office) so there’s no golden rule but the default is generally to browse in the same window (at least it has been for me on all the setups I've seen) so it will open up inside of the IE when you're accessing it through your browser.

having problems integrating pdf document support into Sharepoint 2010?

I now have the icon showing for any pdf documents saved in a Document Lirary, However I don't get the options of Checking out - editing an checking in. There is also no revision control. I think that when I open a pdf document, the servers own copy of Adobe Reader opens, and not my local copy of Reader or Acrobat X pro.

I've done what it says in the Administrators guide for Sharepoint integration and I'm still unable to get this functionality to work. As we use interactivve pdfs for a lot of our internal documentation the pdf integration features are very important.

Slow opening up office files on windows 7Manually fixing error

Posted: March 17, 2008 

by Christian.Updated: October 24, 2010 at 5:13 pm

After upgrading to Excel 2007, you may get the following error when you try to open an excel document:The file you are trying to open .xlsx is in a different format than specified by the file extension. verify the file is not corrupted and is from trusted source before opening the file. Do you want to open the file now?

SharePoint Workspace 2010 – what a messBy tim, on May 25th, 2011 Follow tim on Twitter

For some time I have been meaning to post about SharePoint Workspace 2010. This application was introduced as part of Office 2010, though it is partly based on the older Office Groove software. Its purpose is to allow users to work with documents stored on SharePoint servers even when they are offline. I regard this as an important feature, and since I now store many of my own documents in SharePoint I was quick to install and use it.

I hate it. I am surprised that the Office team released software that is so unreliable, bewildering, overcomplicated, and hard to use even when working as designed. Given that it came out at a time when Microsoft had supposedly got the message about design and user experience, it really is surprisingly bad.

What is wrong with it? All I want to do is to work offline with my SharePoint documents; but the first annoyance is that SharePoint Workspace is designed to accommodate multiple different SharePoint servers. That is not a bad thing in itself, but it means that every time I want to get to my Workspace, I have to go through two steps. First, open the SharePoint workspace Launchbar:

Then double-click Home to open my actual Workspace:

The workspace is Explorer-like, but it is not Explorer. I think this is a mistake. Microsoft should have made this just another folder in Explorer, that works online and offline, and synchronises when connected. Like Dropbox, in fact. But it did not.

Still, I could cope with this if it worked well. Unfortunately it does not. Here was the first unpleasant message I encountered:

“You are storing 196 more documents than SharePoint Workspace supports,” it says. The phrasing is odd. If SharePoint Workspace does not support that number of documents, how come I am storing them?

If you are lucky enough to find it, this document attempts to explain. Here are the limits:

SharePoint Workspace cannot synchronize any files that are larger than 1 GB. Additionally, SharePoint Workspace will stop synchronizing any shared folder that exceeds the following limits: More than 5000 files or a set of files that exceeds 2 GB in total size.

I am way below this though. Why do I get the warning? Maybe because:

For optimal performance in a shared folder, keep the following in mind:

Avoid adding large files (>50 MB) to a shared folder. Avoid adding large numbers of files (>100 files) at once. Avoid storing large numbers of files (>500 files) in a shared folder.

Perhaps then I am within the absolute limit, but above the recommended limit for “optimal performance”. However, this article tells a slightly different story:

You can store approximately 500 documents in SharePoint Workspace. If you exceed this limit, a warning message appears on the Launchbar whenever you start up SharePoint Workspace to remind you that you need to free up space. You can ignore this message and continue to do all SharePoint Workspace activities, though with degraded performance.

If you attempt to create a new SharePoint workspace that would exceed 1800 documents across your SharePoint workspaces, a warning message appears to inform you that only document properties will be downloaded to the workspace.

What then are the limits? 5000 per folder? 500 per folder? 1800 overall? or 500 overall?

If it is 500 overall, that is rather small. What is worse though, SharePoint Workspace lacks any common-sense way to control synchronisation. For example, I would like a global setting that said: Synchronize all documents that changed in the last 90 days, plus others I individually specify.

No such luck. You can connect or disconnect entire libraries, otherwise you can manually set a document to download headers only by right-clicking and choosing Discard local copy. That’s it.

I am not done yet. I get other puzzling errors and messages from this thing, which rarely works as expected. In particular, it is rather bad at its primary function, synching offline changes. To demonstrate this, I decided to record exactly what happens when trying something simple like creating a SharePoint document when offline.

I open SharePoint Workspace when offline. I right-click in a folder and choose New Document. Word opens, which is good. I type my document and hit save. Word opens the Save dialog at the default My Documents location – not where I want it.

However, I can click at top left of the Save dialog where it says Workspaces.

Then I have to navigate back down to the location where I want it and click Save. Eventually I get this notification:

Great, I have managed to create and save a SharePoint document when offline. Except, if I look now in the location to which I have just saved it, it is empty:

However, it does appears in Word’s recent document list and I can open it from there.

Perhaps it will sort itself out when I reconnect. I reconnect. Oh no, here comes an unwelcome notification:

On investigation, I now find my document in another thing called Microsoft Office Upload Center, with a warning mark:

I click Upload all. Nothing happens. I drop down Actions and select Upload. Nothing happens. No error, no upload.

Oddly, if I open SharePoint Workspace, it says it is synchronized. I guess it means synchronized but with errors.

So what is the problem here? Sometimes the problem is that Word is still running. Even if the document is not actually open in Word, some file lock is  not released and it prevents the upload, though you do not get an error message that tells you what is wrong. Not this time though. I could not get it to sync.

I rebooted. Still no joy. I re-opened the document in Word by double-clicking and hit save. Something fixed itself.

I am so conditioned to this kind of rigmarole that I rarely try this now. I store the document locally and copy it to SharePoint when it is online, bypassing the Workspace.

Why do I bother with it? A couple of reasons. One is that the ability to get at your SharePoint documents offline, and to have a kind of additional backup, really is a huge feature, and I prefer one that works badly than to be completely without it. Second, I like to live with these things so that I can assess how well they work. Otherwise we are at the mercy of the press releases that state the existence of the feature but do not describe its limitations.

I hope Microsoft comes up with something better for Office 2012 (or vNext).

Rate this post

Rating: 9.3/10 (3 votes cast)

Related posts:

1. Microsoft Office Live Workspace: what’s missing from the FAQ? 2. Office 2010: the SharePoint factor 3. Hands On with Office Live Workspace beta 4. Live Workspace: can someone explain the offline story? 5. SharePoint 2007 tip: use Explorer not the browser to upload

documents

May 25th, 2011 | Tags: microsoft, office 2010, sharepoint worksp

So you have installed SharePoint (WSS or MOSS) and you have been happily using it for a while now.  Everyone in the office has been taking part in creating some really cool content or loading their sites up with 0some very important information. Now fast forward a few months.  Your local administrator of the server gets in touch with you to let you know that your SQL Server is running low on memory.  What?  How could this be? You start to look for the source of the issue and low and behold you run across a 120 GB database log file.  120 GB????  Yep.  120 GB.You start to think to yourself, “Man, I didn’t know that the SharePoint databases were going to take up this amount of memory.  Maybe I need to purchase an extremely large drive to put the database files on”. Well you could do that.  Or you can modify a few settings and set up a few good maintenance plans and you can reduce that log file down to mere kilobytes.  This actually happened to a few clients of mine.  The main source of the problem is that when most folks install SharePoint they don’t realize that it creates the databases and sets them to Full Recovery Mode.  What this means is the database log (.ldf) file never gets shrunk.  Mainly this is so that if something happens to the database they you have a full history of all of the transactions that have taken place.  But, this is bad for many reasons as well.  Now don’t get me wrong many places have that grumpy DBA that will take care of all of this stuff for you, but I mainly see this in small to medium organizations that don’t have a full time DBA on staff and/or they roll a development farm to production without a lot of forethought on recovery if something goes bad.

Microsoft Office SharePoint Server 2007 (MOSS) and Windows SharePoint Services 3.0 (WSS) gives companies the opportunity to gather data from many sources and publish this on a central location for users to access. But what do the SharePoint administrators need to consider to make sure confidential information is not made available to everyone?

In this article we focus on the challenges of securing data on Microsoft SharePoint sites, lists, pages and the information made available through data-links to backend systems (through BDC and manually created data-links). The audience for this article is primarily the network-/server administrators and SharePoint designers / publishers.

Why do we need to consider securing information?

There are different inputs on what we need to consider when publishing content on SharePoint intranet sites. Sometimes it can be difficult to control the information available if the structure of content and the security access to this is not well planned from the beginning. As the intranet grows the designers and publishers learn how to use SharePoint for team collaboration, document management and dynamic reports. This content is made available for

other employees and here is the key question: What information are they allowed to search for and read? SharePoint, being the place to centralize and structure information, really supports employees and teams work processes but can also be a data security breach if it is not secured correctly.

Let’s begin with an example scenario:

Toy Company A makes key performance indicators (KPI) available on their SharePoint site to show the executives how their department performs financially on a web page. The designer creates a data-connection to the financial database to extract the data. The executives have a blog on the same site where they comment on the KPI every week.

Figure 1: What is behind the nice web part?

In this example the designers have to secure the financial data connection so that only the required information is extracted from the database and to make sure that only the executives can access the data and the blog. The executives must know the importance of this security configuration to ensure and check that the policy is followed. In the worst case the designers use BDC with a full access account to the financial database and make it searchable – and do not limit access to the site for only the executives. In that case every user can search for financial data, read it and the blog comments on the intranet.

Making sure that the intranet is a secure place is a task that must be well planned. If every person from the architect to the end user is aware of this and understands why and how to secure the content (and follow the policies), the intranet is a safe place for your data.

How can users get away with company data?

When we are talking about data security risks the obvious question is: “how can we avoid people seeing or even getting a copy of our confidential information?” Well, today it is very hard to be one hundred percent sure that no one gets a copy and takes it outside the company. Oh yes, it can be done but how many companies have such restrictive security policies around the world? Not many.

The SharePoint infrastructure has a very good “feature” that I like: Users cannot see content that is restricted. YES, that is the way we want it! And with Information Rights Management (IRM) implemented we have great user control. But how can data get out of the SharePoint and be used elsewhere? Of course a SharePoint backup contains a lot of information, so keep these in a place with no user access. But if the users have read access to the content, they could use…

Internet browser

• Copy-paste the data to any application.

• Export the data to an XML-file via the URL protocol (owssvr.dll)

Office products

• Connections and exports can be made to Office applications

• The “Connect to Outlook” can make data available offline and be exported

Other programs

• Calls can be made to the SharePoint farm e.g. through Windows Powershell or other applications

Data copying could be an issue and the tools are right in front of the employees. We can hide links and pages from your users but we need to set correct permissions on the lists, items, document libraries, etc to avoid data copying/loss.

Pinpoint where to check or tighten the security

Okay, now we know why we need to address security on the intranet. Identifying where this can go wrong is the next challenge – and a big one too – and perhaps a bit more technical. Microsoft SharePoint is kind of a large chunk to swallow at the beginning. But working with the individual parts for some time solves the puzzle one bit at a time. As you can see in Figure 2 I have divided into separate sections the different data and how it is connected in the SharePoint structure and arrows of the communication. It simplifies some of the elements and features but gives you a picture of what to look for in your own environment. If you need more details please visit the Microsoft TechNet for full diagrams (see the link section below).

  Figure 2

Notice the question marks? These places are where the security level must be considered. I will start explaining some considerations I thought of from the top of this diagram.

When a user accesses the SharePoint intranet:                 What type of authentication must be used?                 Should the traffic be encrypted with SSL?

SharePoint data is e. g. made by lists, pages and document libraries.                 Should access to some/all of these be restricted in different levels?                                      No Access                                      Readers

                                      Publishers / Editors                                      Administrators                                      Are the administrators of the sites, SharePoint Service Providers (SSP) the correct ones?

Custom pages can contain manually configured data connections.                 Ensure correct permissions is set on the pages/files.                 See “External data sources” below if custom connections is used.

Custom solutions can contain code that access many areas.                 Choose only to install custom solutions you trust.                 Choose the correct security level when installing the solution (see link section).                 See “External data sources” below if custom connections is used.

Search Crawls                 The default content access account has full read access of all web applications in the farm.                 Manually configure read access for the following:                                  SharePoint sites outside the server farm                                  Business Data Catalog applications                                  Web sites                                  File shares                                  Microsoft Exchange Server public folders                                  Lotus Notes

Access to Business Data Catalog (BDC) data                  Choose the correct security access level for users to ensure confidential information is not exposed                    to  everyone.                 Choose the correct authentication method for your BDC connection (see link section).                 If you configure search crawl consider the access to the crawled data.

Custom database connections can be made for the designers.                 Make sure the connections is only available to the employees that needs the information.

External data sources                 Do the data connections use other credentials?                 Can the used credentials access more than needed?                 Use Pass-through/Single Sign-On authentication if possible.                   If RevertToSelf is used, remember this option uses the Application Pool account to access the data                    source.

Service accounts                Only use least privilege rights for your service accounts (see link section).

WSS/MOSS Servers                Secure the server with Antivirus for the OS and SharePoint.                Patch the server with security patches when needed.                Use a firewall to limit the risk of attacks.                Secure the servers physically.                 Keep the central administration port a secret for non-administrators.

MOSS SQL database server (of not on the same server as WSS/MOSS)               Secure the server with Antivirus for the OS and SharePoint.               Patch the server with security patches when needed.               Use a firewall to limit the risk of attacks.               Secure the servers physically.               Use SQL alias and non-standard ports  for communication – especially if DMZ is used.

Network communication               Encrypt the communication between servers if possible.

Use the figure and list above to check how the health of your intranet is and discuss the decisions made for your SharePoint farm. This is not a complete checklist but see it as a guideline for a more secure farm. Small and

medium sized companies tend to tighten security on the box in Figure 2 called “SharePoint Data” but of course this will vary from installation to installation.

Windows 7 - Sharepoint Login problem after upgrade to Windows 7068

Windows 72 posts

 

 

Sharepoint Login problem after upgrade to Windows 7068

I upgraded from 7057 to 7068 version of Windows 7.

After the upgrade, my Sharepoint Designer 2007 is unable to open remote website on front page enabled IIS Server.Also, I am unable to ftp to the site.

This was an upgrade, so all the installed programs were available after the upgrade. All other programs seem to be working fine.

Is there some sort of problem with Windows security...?

Any help will be greatly appreciated. 

Why SharePoint Scares Me 

By Peter Campbell, July 13, 2009

For the past four years or so, at two different organizations, I've been evaluating Microsoft's Sharepoint

2007 as a Portal/Intranet/Business Process Management solution. It's a hard thing to ignore, for numerous

reasons:

It's an instant, interactive content, document and data management interface out of the box, with strong

interactive capabilities and hooks to integrate other databases. If you get the way it uses lists and views

to organize and display data, it can be a very powerful tool for managing and collaborating on all sorts

of content. As I said a year or two ago in an article on document management systems, it has

virtually all of the functionality that the expensive, commercial products do, and they aren't full-fledged

portals and Intranet sites as well.

Sharepoint 2007 (aka MOSS) is not free, but I can pick it up via Techsoup for a song.

It integrates with Microsoft Exchange and Office, to some extent, as well as my Windows Directory,

so, as I oversee a Windows network, it fits into it without having to fuss with

tricky LDAP and SMTP integrations.

All pretty compelling, and I'm not alone -- from the nonprofit CIO and IT Director lists I'm on, I see that lots of

other mid to large-sized organizations are either considering Sharepoint, or already well-ensconced. 

So, why does Sharepoint scare me?

What it does out of the box, it does reasonably well. Not a great or intuitive UI, but it’s pretty powerful.

However, advanced programming and integration with legacy systems can get really complicated very

fast. It is not a well-designed database, and integration is based on SOAP, not the far less

complicated REST standard, meaning that having someone with a strong Microsoft and XML

programming skill set on board is a pre-requisite for doing anything serious with it.

MOSS is actually two major, separately developed applications (Windows Sharepoint

Services and Content Management Server) that were hastily merged into one app. As with a lot of

immature Microsoft products, they seem to have been more motivated by marketing a powerful app

than they were in making it actually functional. Sharepoint 2013 or 2016 will likely be a good product,

kind of like Exchange 2007 or SQL Server 2003, but Sharepoint 2007 makes a lot of promises that it

doesn't really keep.

Sharepoint's primary structure is a collection of "sites", each with it's own URL, home page, and

extensions. Without careful planning, Sharepoint can easily become a junkyard, with function-specific

sites littered all over the map. A number of bloggers are pushing a “Sharepoint invites Silos” meme

these days. I stop short of blaming Sharepoint – it does what you plan for. But if you don’t plan, or you

don't have the buy-in, attention and time commitment of key staff both in and out of IT, then silos are the

easiest things for Sharepoint to do.

The database stores documents as database blobs, as opposed to linking to files on disk, threatening

the performance of the database and putting the documents at risk of corruption. I don't want to take my

org's critical work product and put it in a box that could easily break.

Licensing for use outside of my organization is complicated and expensive. MOSS access requires two

or three separate licenses for each user - a Windows Server licence; a Sharepoint License, and, if

you're using teh advanced Sharepoint features, an additional license for that fiunctionality. So, if I want

to set up a site for our Board, or extend access to key partners or clients, It's going to cost for each one.

There's an option to buy an unlimited access license, but, the last time I looked, this was prohibitively

expensive even at charity pricing.

Compared to most Open Source portals, Sharepoint's hardware and bandwidth requirements are

significantly high. Standard advice is that you will need additional, expensive bandwidth optimizing

software in order to make it bearable on a WAN. For good performance on a modest installation, you'll

need at least two powerful servers, one for SQL Server and one for Sharepoint; for larger installations, a

server farm.

I can't help but contrast this with the far more manageable and affordable alternatives, even if those

alternatives aren't the kitchen sink that Sharepoint is. Going with a non-Microsoft portal, I might lose all of

that out of the box integration with my MS network, but I would jettison the complexity, demanding

resources, and potential for confusion and site sprawl. I'm not saying that any portal/intranet/knowledge

management system can succeed without cross-departmental planning, but I am saying that the risk of a

project being ignored -- particularly if the financial investment was modest, and Sharepoint's not cheap, even

if the software can be -- is easier to deal with than a project being fractured but critical. 

if my goal is to promote collaboration and integrated work in my organization, using technology that

transcends and discourages silos, I'm much better off with apps like Drupal, KnowledgeTree, Plone,

or Salesforce, all of which do big pieces of what Sharepoint does, but require supplemental applications to

match Sharepoint's smorgasbord of functionality, but are much less complicated and expensive to deploy. 

After four years of agonizing on this, here's my conclusion: When the product matures, if I have

organizational buy-in and interest; a large hardware budget; a high-performance Wide Area Network, and a

budget for consulting, Sharepoint will be a great way to go. Under the conditions that I have today -- some

organizational buy-in; modest budget for servers and no budget for consulting; a decent network, but other

priorities for the bandwidth, such as VOIP and video -- I'd be much better served with the alternatives.