1. 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
2. ** 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?
3. Opening Files in Their Native Programs With
SharePoint
When 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.
4. Slow opening up office files on windows 7
Manually 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 mess
By 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:
5. 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
6. 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:
7. 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.
8. 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.
9. 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
10. 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
11. 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).
12. 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
13. 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
14. 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 7
2 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
15. 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.
16. 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.