Word text generator for Lorem Ipsum

Regularly I need Word documents with example text. Word has a example text generator feature which creates text like “Lorem ipsum dolor sit amet, consectetuer …” or “On the Insert tab, the galleries include items that are designed …” or “The quick brown fox jumps over the lazy dog. The quick brown fox …”.

Simply start Word and type =lorem(3,10) and press Enter

Word 2010, lorem ipsum function

This results in:

Word 2010, lorem ipsum result

There are some options you can use:

  • =lorem(p, l) where p is the number of paragraphs and l the number of lines per paragraph.
  • =rand(p,l) provides the same functionality but using different text “On the Insert tab, the galleries include items that are designed …
  • =rand.old(p,l) also provides the same functionality using different text “The quick brown fox jumps over the lazy dog. The quick brown fox …

Article from: http://bramdejager.wordpress.com/2011/08/

Avoiding Xml Based SharePoint Features – Use The API Way

Developing solutions and features for SharePoint is a nightmare for all beginners, and even for the experienced SharePoint developers. If you ever have had the opportunity to create a SharePoint solution you most probably have had to make a lot of hacking in a bunch of XML files, just to build a simple feature. This is the way you have to do it, and the way taught by tutors and Microsoft, when using it with Visual Studio and no add-ins. This is the way it was, and has been, for most of us SharePoint programmers since the beta releases of SharePoint version 3.

Nowadays you have several tools that help you out; such as Visual Studio Extensions for WSS, WSPBuilder, STSDev and more. Some have a user interface that helps you a lot; such as VSeWSS and SPVisualDev and some does not help much there; such as STSDev. But whatever tool you use you will find that you are digging yourself deep into hacking those Xml files. Unfortunately the documentation is quite poor, but we have the fantastic SharePoint bloggers and MVPs that made their code and samples available throughGoogle, sorry Bing.

Lots of XML

For example when you have a site and you would like to create a custom list, you will have to define a Content Type, a list schema, a list template and a list instance and then you have a feature manifest and a solution manifest – that counts to at least five different XML files and a few different schemas. This is an awful amount of job in the beginning and I think in some cases it’s a waste of time, especially if it’s a custom list that only will be used once. Then we have the thing when we want to update the list or content type when it’s deployed…a whole lotta XML in combination with compiled code (for example when updating Content Types)!

I have in my recent projects abandoned the XML way (declarative/CAML) in favor of the The API way (Object Model).

The API Way

Almost everything that these XML files can do can be done using compiled .NET code and utilizing the SharePoint API’s. Take the example above – those XML files can be replaced with a few lines of C# code. Create a Content Type, create a List, add a Content Type to the List. There are still few XML files left; the feature and solution manifests; but those two are easy to handle.

All you have to do is put this initialization and creation code in the Feature Receivers of the Features.

Upgrading and developing these features using the API way are also very easy and straightforward. I think it also fits better into a TDD kind of development way. If you have a list that is created through the Feature Receiver and you find that you need to add a field to that list, I just de-activates and activates that feature. This is done by a set of extension I use to create fields if they don’t exist, in Lists or Content Types.

API way – Pros

Using the API way has several benefits:

  • As a beginner, but experienced .NET developer, it might be easier to start working with the SharePoint API
  • Mistakes are easier discovered:     
    • You have to deploy and test your feature to find small mistakes in the XML
    • Some errors are detected during compilation phases
  • Debugging – yea try that with XML based features!
  • Upgrading experience is far much better (de-activate and activate)
  • Development time is most often faster, just re-register the assembly
  • Easy to staple the feature, and it’s receiver, to Site Defintions
  • Testing, and TDD, is possible even outside of the SharePoint scope

API way – Cons

Of course there are cons of using the API way. First of all there are some things that you can’t do

  • Create List Templates – for reusable lists, i.e. lists available for the end-user to create
  • Create Site Definitions
  • Create Custom Actions
  • Configure Delegate Controls

The cons with the API way are for example:

  • Requires installation of assemblies in the GAC     
    • This is in many installations prohibited due to the fact that it requires that you run in full trust.
  • I find it easier in some situations to re-use configurations created in XML files
  • When using XML definitions you can specify ID’s of Content Types etc which are required in many situations, for example when you are re-using your Content Type in many farms or Site Collections.
  • Requires that you really understand how the provisioning works in SharePoint
  • Requires that you take care of the clean-up when deactivating

Most pros and cons are of course a personal consideration, but as I said, I almost every time nowadays use the API way for my features.

How do you develop your Features, Lists and Content Types?

Basically I try to have a clean and simple Site Definition and then staple my features and it’s receivers onto that Site Definition. It comes down to very little XML and some compiled code – very maintainable.

Article from: http://www.wictorwilen.se/Post/Avoiding-Xml-Based-SharePoint-Features-Use-The-API-Way.aspx

How To disable the Shutdown Tracker in Windows Server 2008 R2

I use a Windows Server 2008 R2 machine that is installed on my Lenovo W510 laptop to do demonstrations almost every day.  Normally I would recommend that you leave your servers running all the time, however in this case I have a limitation of battery life that does not allow that practice and so I end up shutting the server down almost every day.  As you are aware when you shut down Windows Server 2008 R2 there is a cool feature that prompts you for a reason why you are shutting down the server.  The feature is called the Shutdown Event Tracker.  Again normally I love the shutdown tracker because it provides historical context to the reasons for shutting down a server.  In my case it is an annoyance that slows the process of shut down.  So the question is how do you disable the shutdown event tracker?

1.  Open Group Policy editor.  You could use MMC and add the local group policy snap in or you can simply click on Start and then type gpedit.msc.

shutdown tracker gp

2. Navigate to Computer Configuration / Administrative Templates / System

3. Find the setting called “Display Shutdown Event Tracker” You will have to scroll down a little to get past the containers of settings and then find it. 

shutdown tracker 1

4. Double click “Display Shutdown Event Tracker”  This will open the settings for the policy. 

shutdown tracker3

5.  Because the policy says “Display Shutdown Event tracker” its default behavior when not configured is to display the tracker.  We want it to go away so we will select the radio button to “Disable” the setting. 

6. Click OK, then close the local group policy editor.

And there you have it! No more Shutdown Event Tracker!

An additional note.  As you change the setting for this group policy it is also important to note that the same shutdown tracker could also be implemented on the workstation side of your network if you should choose to do so, and both server and workstation operations for Shutdown event tracker are managed from this single group policy setting. 

Article from: http://blogs.technet.com/b/chenley/archive/2011/03/05/how-to-disable-the-shutdown-tracker-in-windows-server-2008-r2.aspx

Restoring Windows Server 2008 to Bare Metal

This article demonstrates how to restore a backed-up Windows Server 2008 R2 installation to a bare metal system that has no operating system installed on it.


Successful disaster recovery is all about preparation because bad things happen when you least want them to. There are several different ways you can restore a Windows server when the system drive fails on it. The approach we’re going to walk you through here is simple and straightforward: just replace the failed drive, boot the server from Windows installation media, and launch the restore process. There are a couple of things to watch for however when you do this as we shall shortly see.

Test Environment

For simplicity, the walkthrough performed below uses a virtual environment running on Microsoft Hyper-V. The server we’re going to restore is a virtual machine named SEA-FS1 in the contoso.com domain. The backup will be saved to a shared folder on the Hyper-V host on which this virtual machine is running. And the “bare metal system” to which we’re going to restore the backup is another virtual machine that has no operating system installed on it. But the steps listed below are the same as if you were backing up a physical server and restoring it to actual bare metal. 

Backing Up the Server

Let’s begin. Figure 1 below shows our file server before it “crashes” and needs to be restored. The server name and domain are circled in red, and the title bar of the Virtual Machine Connection window also shows the server’s name:

Figure 1: The server before it crashed

We’ll map a drive letter to a shared folder named Backups on the Hyper-V host machine so we can store our backup “on the network” when we create it:

Figure 2: Preparing to back up the server

We enter credentials for accessing the shared folder on the host:

Figure 3: Preparing to back up the server

As you can see there are currently no backup sets in the shared folder:

Figure 4: There’s no backup yet

Now we’ll type “backup” in the Start menu search box to bring up the Windows Server Backup feature (which of course must be installed on your server before you can use it):

Figure 5: Step 1 of backing up the server

When the Windows Server Backup window opens, click Backup Once as shown here:

Figure 6: Step 2 of backing up the server

On the Backup Options page of the wizard, make sure Different Options is selected:

Figure 7: Step 3 of backing up the server

On the Select Backup Configuration page, select Custom:

Figure 8: Step 4 of backing up the server

On the Select Items For Backup page, click the Add Items button:

Figure 9: Step 5 of backing up the server

In the Select Items dialog, select the checkbox labeled Bar Metal Recovery. Doing this will automatically select all other checkboxes as well:

Figure 10: Step 6 of backing up the server

Clicking OK returns you to the Select Items For Backup page. Click Next on this page:

Figure 11: Step 7 of backing up the server

On the Specify Destination Type page, select Remote Shared Folder:

Figure 12: Step 8 of backing up the server

On the Specify Remote Folder page, we type the UNC path to the shared folder on the “network” where we will be storing our backups. The path we specify is \\HV-1\Backups and we leave the other options on the page at their defaults:

Figure 13: Step 9 of backing up the server

At the credential prompt, we specify credentials for accessing the shared folder on the host machine:

Figure 14: Step 10 of backing up the server

After reviewing the Confirmation page below, we will click Backup to begin backing up the server:

Figure 15: Step 11 of backing up the server

The server is being backed up:

Figure 16: Step 12 of backing up the server

Backup is finished:

Figure 17: The server has been backed up

We open the mapped drive in Explorer to verify the backup set is there:

Figure 18: The server has definitely been backed up

Now we shut down our file server and close the virtual machine. We’re ready to restore to bare metal!

Restoring the Server to Bare Metal

Figure 19 below shows a virtual machine named Bare Metal System. As you can see, when we try to boot the system the boot fails because there is no operating system installed on the machine:

Figure 19: This bare metal system has no operating system installed

To launch the recovery process, we need to boot our bare metal system using Windows media. Since our system is a virtual machine, we simply attach an .iso image of Windows Server 2008 R2 installation media in the settings for the virtual machine and then restart the virtual machine. In a few seconds the Install Windows dialog comes up:

Figure 20: Step 1 of restoring to bare metal

After clicking Next in the previous screen, we now select the Repair Your Computer option at the bottom left as shown here:

Figure 21: Step 2 of restoring to bare metal

In the System Recovery Options dialog, we select the “Restore your computer using a system image that you created earlier” option:

Figure 22: Step 3 of restoring to bare metal

When the Re-image Your Computer dialog appears, we click Cancel:

Figure 23: Step 4 of restoring to bare metal

Note:# If the backup you were restoring from resided on a hard drive attached to the system (for example an external USB drive) this Re-image Your Computer dialog won’t be displayed. Instead, you’ll be taken directly to the next screen below where you will select the first option “Use the latest available system image (recommended)” and proceed with the restore process.

On the Select A System Image Backup page, make sure Select A System Image is selected and click Next as shown here:

Figure 24: Step 5 of restoring to bare metal

The next page should not show any backups available. The reason is because we’ve backed up our server to the network (to a file share on our host machine) and not to a local drive on the system or attached USB drive. If you had backed up to a local or attached drive instead of the network, you would continue the restore process starting at Figure 30 below.

On the page shown below, click Advanced:

Figure 25: Step 6 of restoring to bare metal

In the dialog that appears, select the “Search for a system image on the network” option as shown here:

Figure 26: Step 7 of restoring to bare metal

Note: The test environment for this walkthrough has a DHCP server and this is how the Windows Recovery Environment is able to connect to the network share where the backup set is located.

In the Are You Sure dialog that appears next, click Yes:

Figure 27: Step 8 of restoring to bare metal

Note: As the dialog above indicates, restoring a system from a backup stored on the network is not as secure as restoring the system from a local or attached drive, so take this into consideration when planning your disaster recover infrastructure for your servers!

Type the UNC path to where the backup is stored on the network:

Figure 28: Step 9 of restoring to bare metal

Specify credentials needed to access the network share:

Figure 29: Step 10 of restoring to bare metal

Once the Windows Recovery Environment has connected to the network share you should see a list of available backup locations on the share. Select the one you want and click Next as shown here:

Figure 30: Step 11 of restoring to bare metal

Now select the backup set you want to restore from:

Figure 31: Step 12 of restoring to bare metal

Clicking Next brings up the Choose Additional Restore Options page:

Figure 32: Step 13 of restoring to bare metal

If you click Advanced, you can see that the system will automatically restart once the restore process is finished and will also check the disk for errors. We’ll leave both of these options selected:

Figure 33: Step 14 of restoring to bare metal

Clicking Next asks us to confirm our selections:

Figure 34: Step 15 of restoring to bare metal


Figure 35: Step 16 of restoring to bare metal

Now we get an error message:

Figure 36: The restore failed!

Oops, what went wrong? Let’s try the restore process again starting from Figure 19 again…

Rats, this time we get a different but even worse error:

Figure 37: The restore failed again!!

We click the Details link in the above dialog box and get this in response:

Figure 38: Thanks a lot for the advice

What could be wrong? A bit of Binging around on the Internet brings up this thread from the Microsoft TechNet Forums.

The person who answered the original poster’s question is right on the money because when I open the settings for my Bare Metal System virtual machine in Hyper-V Manager, I see that the virtual hard drive on this machine is in fact smaller in size than the VHD on my original system SEA-FS1.

LESSON LEARNED: Make sure the hard drive of the bare metal system you are restoring to is equal to or larger in size than the hard drive of the system that failed.

To fix this, we detach the VHD file from the Bare Metal System VM, create a new VHD equal in size to the one attached to the SEA-FS1 VM, and restart our restore process beginning with Figure 19 again, and this time the restore process works:

Figure 39: The restore is now working, whew!!

Once the restore to bare metal finishes and the machine reboots, we log on and verify that our recovered server has the same name as our original server (compare the figure below with Figure 1 at the beginning of this article):

Figure 40: The restore is finished.

Article from:  http://www.windowsnetworking.com/articles-tutorials/windows-server-2008/Restoring-Windows-Server-Bare-Metal.html