 |
| Open Document in Vizit | /_layouts/Vizit/Previewer/Images/vizit_logo_icon.png | javascript: if(!window.Vizit){ Vizit = new Object();} Vizit.CurrentContext = currentCtx; Vizit.CurrentItemId = currentItemID; if(!window.ShowViewer) { var elemTable = document.getElementById("ECBItems"); if(elemTable != null) { var elemTBody = elemTable.childNodes[0]; for(var i=0; i < elemTBody.childNodes.length; i++) { var elemTR = elemTBody.childNodes[i]; if(elemTR.childNodes[0].innerHTML == "Open Document in Vizit") { var imageUrl = elemTR.childNodes[1].innerHTML; Vizit.WebUrl = imageUrl.substring(0, imageUrl.indexOf("_layouts/Vizit/Previewer/Images/vizit_logo_icon.png")); var jsUrl = Vizit.WebUrl + "_layouts/Vizit/Previewer/JavaScript/component.js?ver=0.0.0.0"; var fileref = document.createElement("script"); fileref.onreadystatechange = fileref.onload = function() { if(fileref.readyState == "loaded" || fileref.readyState == null) ShowViewer(Vizit.CurrentContext.listUrlDir, Vizit.CurrentItemId); }; fileref.setAttribute("type", "text/javascript"); fileref.setAttribute("src", jsUrl); document.getElementsByTagName("head")[0].appendChild(fileref); break;}} } } if(window.ShowViewer) ShowViewer(Vizit.CurrentContext.listUrlDir, Vizit.CurrentItemId); | 0x0 | 0x0 | ContentType | 0x010 | 2147483647 |
|
|
| Open Document in Vizit | /_layouts/Vizit/Previewer/Images/vizit_logo_icon.png | javascript: if(!window.Vizit){ Vizit = new Object();} Vizit.CurrentContext = currentCtx; Vizit.CurrentItemId = currentItemID; if(!window.ShowViewer) { var elemTable = document.getElementById("ECBItems"); if(elemTable != null) { var elemTBody = elemTable.childNodes[0]; for(var i=0; i < elemTBody.childNodes.length; i++) { var elemTR = elemTBody.childNodes[i]; if(elemTR.childNodes[0].innerHTML == "Open Document in Vizit") { var imageUrl = elemTR.childNodes[1].innerHTML; Vizit.WebUrl = imageUrl.substring(0, imageUrl.indexOf("_layouts/Vizit/Previewer/Images/vizit_logo_icon.png")); var jsUrl = Vizit.WebUrl + "_layouts/Vizit/Previewer/JavaScript/component.js?ver=0.0.0.0"; var fileref = document.createElement("script"); fileref.onreadystatechange = fileref.onload = function() { if(fileref.readyState == "loaded" || fileref.readyState == null) ShowViewer(Vizit.CurrentContext.listUrlDir, Vizit.CurrentItemId); }; fileref.setAttribute("type", "text/javascript"); fileref.setAttribute("src", jsUrl); document.getElementsByTagName("head")[0].appendChild(fileref); break;}} } } if(window.ShowViewer) ShowViewer(Vizit.CurrentContext.listUrlDir, Vizit.CurrentItemId); | 0x0 | 0x0 | ContentType | 0x010 | 2147483647 |
|
|
Windows
Live™

Public SkyDrive

|
|
 |
|
|
|
|
|
|
|
|
4/27/2011
Made some changes to the build guide related to Windows 7 alternatives for SharePoint 2010 development.
As a SharePoint Developer or Administrator, you may already know that there are various options available to create a local installation for build, debug and test; you either go with a complete host version or a virtual. With the pending beta release of SharePoint 2010 in November, there has been a lot of interest in the changes to additional supported approaches to development on Windows 7 and Vista which can be used in lieu of a full Server 2008 farm based version.
Yes, it is nice to have all the tools you need installed on the workstation / laptop you use on a daily basis - if you are interested in this development environment approach using Windows 7 or Vista x64, please refer to Microsoft’s Developer Center guide. Keep in mind there are various alternate setup steps for a developer workstation than a complete Server OS / SharePoint instance outlined in this guide.
This ‘Part 1’ build guide is complete and includes starting with the Windows Server 2008, SQL Server 2008 and prerequisites to installing SharePoint 2010.
( SharePoint 2010 Developer Build Guide – Part I - PDF )
‘Part II’ will examine basic farm services and required configuration settings. This complete virtual build took me 3-4 hours and was configured using a 2.0GHz laptop with 2GB of RAM along with some external storage - less than best-in-class for sure.
2/9/2009
Most of the larger-scale SharePoint deployments that I have been involved with over the last 6 years has included some type of virtualization included in the architecture, either through SQL virtual clustering, or with one or more of the farm server roles assigned as a VM Web Front End / Query, Indexing or a hot-spare application server. Many companies today are rapidly deploying fewer physical servers to handle all the SharePoint tasks of many physical servers and assuming that they can spin up as many as they see fit and obtain close to the same results as a physical environment.
Depending upon your particular method for determining the correct hardware requirements, you may or may not have taken into consideration the 'gotcha' aspects of virtualizing your SharePoint farm design – one that gets very little attention: Performance Monitoring
Performance monitoring in a virtualized environment, either through VMWare or Hyper-V is not as straightforward as monitoring a non-virtualized environment. I have seen one environment where 3-4 VM servers deployed had more resources assigned in total than the physical host had available. (Similar to banks leveraging 30x what they had in deposits over the last decade.) The VM is unaware of the fact that its configuration and assigned resources are virtualized. VMWare ESX and Microsoft Hyper-V based virtual environments share the physical state of the parent server. If you were to rationalize all of the VM CPUs, you would likely have a skewed view of the real system CPU utilization available within the host VM server.
For example, let's say you are beginning to see performance degradation on your SharePoint environment, so you remote in to you WFE and look first at the task manager 'performance' tab. You may be thinking, the server is underutilized, what could be the problem?
Although looking at task manager 'performance' and Perfmon is the place to start troubleshooting, if things seem ok here, you may need to go to the host / parent server for a more comprehensive view. (Can anyone say Governance here?) Since the CPU utilization you would see on the app server is only a snapshot of the local VM, it is in no way related to VM's parent server. This server is sharing the physical processors with the other VM instances in the farm. (To clarify, if architected correctly, with an even VM distribution, Perfmon can give you fairly accurate counters to help you tune your MOSS environment through page file, memory or application pool configuration changes.)
Everything looks fine here, so where do I look? VMware and Hyper-V have their own performance counters that are the best source of troubleshooting. These counters are related to non-SharePoint entities. Hyper-V calls them 'Guest' / 'Hypervisor' and VMWare calls them 'VirtualMachine' / 'Host System'. In the follow-up blog, 'Troubleshooting Virtualized SharePoint Farms - Part II', which will be published soon, I will give some detailed information around troubleshooting through performance monitoring. Until then, I hope that these links can help you with further information related to MOSS and VM performance troubleshooting:
Microsoft Hyper-V:
VMware:
1/22/2009
If you are a developer keeping up with the latest on ASP.NET, SharePoint or other types of Hybrid / Rich Internet Application development, you may already understand the evolution of Microsoft's Software + Services offerings and Windows Azure. Although SharePoint Services in Azure are not yet available, we will hopefully see something before Azure Beta. You can only assume that part of this late release strategy is to include support for new SharePoint 2009 features; Master Data Management, Knowledge Network, Social Computing, or maybe a Visual Studio 2008 Server Explorer extension for Azure SharePoint Services, etc.? Microsoft has stated that those plans are still being made and that the best plan is to continue writing code to the SharePoint APIs and Web Services that are available now in Microsoft SharePoint Online. The topline cloud applications are ready today.
While waiting for SharePoint Services in Azure, you can begin to develop, deploy, and manage scalable services in the other core services of Azure available today.
Requirements
XP is not supported for the Development Fabric simulation. You can try but it is not recommended. The reason for this is that the SDK provides the developer the ability to write hosted applications and therefore requires Vista SP1 or Windows Server 2008 to properly simulate the Azure cloud environment. The dependency on Vista SP1 or Windows Server 2008 is for the Azure Development Fabric, the simulated execution environment for hosted services. The relationship is analogous to ASP.NET development and IIS, ergo, Azure Services Platform requires this local Development Fabric.
This is a big ouch for the masses of existing .Net developers wanting in to the Microsoft version of cloud services, but remember it's still pre-beta so an isolated virtual environment based on Windows Server 2008 is still the best way to go.
Windows Azure SDK provides developers with the tools and APIs needed to get started and yes, there is a LOT to learn. Ray Ozzie and others have clearly stated a pretty straightforward vision that, whether you are using Azure, Amazon's EC2 or other vendors for cloud computing services and infrastructures, developers will need to contend with new programming models sooner or later. The way a developer will write code, deploy it, debug it, and maintain it will be transformed.
Like Microsoft SharePoint Online hosting, Windows Azure cloud services for SharePoint will be huge since it simplifies the IT Service Management portion of SharePoint Governance. The infrastructure design, service hosting and management is already baked in! This allows companies to save tremendously with the Azure pay as you grow approach and will relieve operational constraints.
1/19/2009
I've just finished a developer guideline doc in the free doc library showing how to setup multiple MOSS 2007 Virtual Machines with Virtual PC 2007 along with information on how to properly distribute and avoid networking and configuration issues when creating a developers library of VM images.
You may have spent many hours building out your Virtual Server or Virtual PC image and now want to distribute a copy of your virtual image to others on your team inside a corporate network. It's easy to just to grab an external USB drive and give someone a copy. Well, in order to avoid network conflicts where the same Virtual Machine in a domain workgroup could have IP DHCP conflicts with duplicate server names and SQL instances, you'll need to understand how to resolve and rename your server instances.
This document assumes that as a Developer / IT Pro, you have already considered the pros and cons of virtualized IDE's and the products that are widely available today and that you have a base image somewhere, created using similar instructions like the steps listed here on MSDN.
I've read through some pretty decent blogs in the few years focusing on SharePoint development and how to utilize Virtual Server, Virtual PC2007 and VMware for MOSS, WSS and ASP.NET development. Some books contain details around development in VPC or Virtual Server but most never explain the pros and cons well enough to know more than what the author simply preferred. Virtual PC, other than being free-as-in-beer, lends itself to ease-of-use, customization, and distribution among developers. (See my favorite list of blog articles on VM based development)
For a complete development system, each build could take up to 8 hours or more. The purpose of this document is to reduce those efforts to a fraction of the time require to build each VPC and with far fewer steps than it would take to copy all of the required media and repetitively to create a new server VPC for each developer on your team.
In short, this document shows you how to copy, rename and reuse a base image over and over to distribute to others without conflict. I hope it's helpful! 10/27/2008
The KPI list in the MOSS Report center main page http://MOSSSERVER/reports is pretty straight forward with the exception of how to integrate Analysis Services KPI data beyond a single KPI measure indicator - Red, Green or Yellow.
Dashboards are primarily Web Part pages that can be used to show XLS Reports, (Excel files that are published to a MOSS library) spreadsheet based pivoted data info that is either comprised of SSAS, SQL or some other OLE DB data via a connection embedded in the worksheet
Some background with Excel will be helpful with more advanced methods of obtaining and reporting on your data without touching SQL Server Client Tools, BI Tools or Visual Studio. Ultimately, it may help you understand some out of the box reporting limitations of MOSS with regards to KPIs. This simple walk-through will demonstrate some of the flexibility and power by which to report KPI measures from a multidimensional cube in a MOSS dashboard.
Starting with Excel 2007, Select the Data tab and then Connections
Click Add > Browse for More
Select "Connect to a New Data Source"
Next the connection wizard will present the obvious option:
Enter the server name (screenshot not show) and it should present you with SSAS and table / cube database (permissions apply)
For this example we have a single cube on the server
Select Database and Table and click Next
Save and Finish
If this is the first system defined data source that you have made in Office from your PC, then after configuration in Windows XP a new folder below My Documents will be created called My Data Sources containing your new Office Data Connections which are important not only for this Excel based view of SSAS data, but also for re-use within the MOSS Portal "Report" Data Connection library. The connection file is Office XML that defines the connection a portion of which is shown below:
<odc:ConnectionString>Provider=MSOLAP.3;Integrated Security=SSPI;Persist Security Info=True;Data Source=SQLSERVERNAME;Initial Catalog=ssas_ebr_east_udm</odc:ConnectionString>
Once the connection configuration is complete the current Excel Workbook when saved will always reference the cube.
When publishing this to MOSS, Excel Calculation Services has some caveats as to how this data is refreshed and displayed, so be sure to set the properties on the definition tab to Always use connection file.
(For more information on this, see the MOSS Portal based help files on "Refresh External Data in Excel Services")
In Excel, now select the Data Tab and the ribbon drop down, "Existing Connection".
Select your new SSAS connection and place the display of the data type you want into the worksheet as shown
Excel can show the KPI's as defined within the cube's dimensions and expressions. This can in turn be published to a MOSS Report library. A Dashboard page is then built with a view of this information through the Excel Web Access web part.
Additional, we can re-use these steps taking the ODC file we created via Excel and upload that to the Data Connection Library. This is required to use Analysis Service Data in a KPI list. A KPI list can be a mixed list of rows displaying manually entered information list as well as SSAS data. Getting even more complex, KPI's data can be pulled from dynamic lists.
MOSS has an option of using SSAS Indicators in a KPI list, These can be shown with or without the colored SSAS KPI Status Red, Orange Green. (More info to follow in Part 2)

Some clients I have worked with have taken hold of Excel Services and are asking for clarification on requirements for publishing Excel Services Web based workbooks. Per Microsoft documentation, you need Microsoft Office Ultimate 2007, Office Professional Plus 2007, Office Enterprise 2007 and obviously, Office Excel 2007. Since you get Office Excel 2007 throughout the entire Office 2007 product line (see table below) there's some clarification needed here: In order to get the enhanced UI in Excel using the Publish menu and subsequent 'Save As' options to hide or expose workbook data, you will need one of the prior mentioned Office flavors.
Excel Services Publish options between Office versions.
Options available within Office 2007 Plus, Enterprise and Ultimate.
So, even if you have Office Home, Office Student, Standard and Small Business or Professional (Not Plus, Ultimate or Enterprise) you can still publish through 'Save As' by entering the full path to the Document Library http://server/DocumentLibrary/ Of course all MOSS farm server Excel Services settings are still required for web browsing to the published workbooks. Click here for the Channel 9 video download which outlines some of those requirements. Yes, you will lose out on a lot of Excel Services options as shown in the same video but you can still publish the 2007 versions (XLSX) of your workbooks straight into an Enterprise version of MOSS and view through clicking on the workbook in the doc lib or the Excel Web Access Web Part.
See Also: http://office.microsoft.com/en-us/products/fx100487411033.aspx
|
Product Suite |
Excel Services Publishing Options |
|
Office Home and Student 2007 |
Save As |
|
Office Standard 2007 |
Save As |
|
Office Small Business 2007 |
Save As |
|
Office Professional 2007 |
Save As |
|
Office Professional Plus 2007 |
Publish |
|
Office Enterprise 2007 |
Publish |
|
Office Ultimate 2007 |
Publish | 10/23/2008
Here's a great MOSS feature for large organizations with concerns about users that should not be deleting sites; where the Site Collection Administrator may have given a particular user elevated permissions that they should not have been given. I have some client's asking about some further description around this since they are new to SharePoint and have not had the prior experiences with sites recovery and working with content.
http://www.codeplex.com/governance
http://www.codeplex.com/governance/Release/ProjectReleases.aspx?ReleaseId=3830
There is no OOTB setting to prevent this without proper training of Misys Site Collection Administrators. They should know what level of permissions to assign their departmental users. This is a feature to archive and email the Site Collection Admin that the site has been deleted. When you build sites for your users, be sure to assign someone in the IT staff as one of the two Admins on the site so you will receive the email as well.
A Site Collection Admin can give someone full permissions to a site collection or subweb allowing them to accidentally delete any site. This feature is like a second stage recycle bin and prevents you from having to get the SQL folks like Doug involved.
If a user was to delete a subweb you could restore a stsadm.exe scripted backup of the site collection, but this feature takes the last state of the content prior to deletion and saves it to a local UNC path (preferably, one of the front end webs with a Share that has sufficient space.
Keep in mind that if you deploy this feature, then a site collection, no matter how large will be archived accordingly. This is why it is good to set EACH site collection with an appropriate Quota Template, say, no larger than 10GB.
Of course, as always with Codeplex 'source', I would recommend deploying / testing on a Dev instance or VHD.
| Open Document in Vizit | /_layouts/Vizit/Previewer/Images/vizit_logo_icon.png | javascript: if(!window.Vizit){ Vizit = new Object();} Vizit.CurrentContext = currentCtx; Vizit.CurrentItemId = currentItemID; if(!window.ShowViewer) { var elemTable = document.getElementById("ECBItems"); if(elemTable != null) { var elemTBody = elemTable.childNodes[0]; for(var i=0; i < elemTBody.childNodes.length; i++) { var elemTR = elemTBody.childNodes[i]; if(elemTR.childNodes[0].innerHTML == "Open Document in Vizit") { var imageUrl = elemTR.childNodes[1].innerHTML; Vizit.WebUrl = imageUrl.substring(0, imageUrl.indexOf("_layouts/Vizit/Previewer/Images/vizit_logo_icon.png")); var jsUrl = Vizit.WebUrl + "_layouts/Vizit/Previewer/JavaScript/component.js?ver=0.0.0.0"; var fileref = document.createElement("script"); fileref.onreadystatechange = fileref.onload = function() { if(fileref.readyState == "loaded" || fileref.readyState == null) ShowViewer(Vizit.CurrentContext.listUrlDir, Vizit.CurrentItemId); }; fileref.setAttribute("type", "text/javascript"); fileref.setAttribute("src", jsUrl); document.getElementsByTagName("head")[0].appendChild(fileref); break;}} } } if(window.ShowViewer) ShowViewer(Vizit.CurrentContext.listUrlDir, Vizit.CurrentItemId); | 0x0 | 0x0 | ContentType | 0x010 | 2147483647 |
|
|
|
|
|
|
|
|