Innovative Enablement of UX Drives Adoption

In Software Development, “Why you put User Experience before Programming?” The reason being that the UX is an integral component of problem solving. It is an essential discipline to follow when building a solution. UX gives a developer a clear direction and makes a strong impact in delivering software solutions. Without UX you can successfully implement a crappy solution which no one will adopt.

There are plenty of software out there are crappy, unusable and bloated with unnecessary features. No matter how effective, configurable, or powerful a software product may be, if users can’t learn to adopt to it quickly and painlessly, its value will be diluted.

Set a web template’s welcome page URL declaratively without using the publishing feature

To set a custom welcome page in a web template using no-code and no-publishing, do the following

  1. Create a web-scoped feature, e.g. WebTemplatePropertyBagFeature
  2. Add your code to an element like the one below (I am keeping a webtemplate id value property, just to show how you can have multiple values set via one single property bag feature):
<?xml version="1.0" encoding="utf-8"?> <Elements xmlns=""> <PropertyBag ParentType="Web"> <Property Name="Readify.Pwcs.Intranet.Collaboration.WebTemplateId" Type="string" Value="PWCSTeamSite" /> </PropertyBag> <PropertyBag Url="" ParentType="Folder" RootWebOnly="FALSE"> <Property Name="vti_welcomepage" Type="string" Value="SitePages/Home.aspx" /> </PropertyBag> </Elements>

Sending email from SharePoint on-premises via Office 365 – Client SMTP Submission

Installing a local SMTP Relay

The first step is to install an IIS SMTP server that will be used for relaying messages from SharePoint. This can be accomplished by using the ‘Add Roles and Features’ wizard, after completion will add a new option “Internet Information Services (6.0)” in the Server Manager ‘Tools’ menu. This is the interface by which we’ll configure the SMTP server, pictured below:


Configure SMTP Virtual Server Settings

By default the server listens to all addresses on port 25 which is the default SMTP server port, and Anonymous access is enabled; no changes are required to either of those items for our scenario. However, to ensure that we don’t relay messages from any machine we’ll limit the systems that are able to connect to and send through our server. From the “[SMTP Virtual Server #1] > Properties > Access” tab, click the “Connection” button which brings up the following window:


Be sure to specify the IP Address of each of the servers from which messages will be sent. Typically, multiple IP addresses are bound to each SharePoint server to support SSL bindings – be certain to list each of the addresses. In this screenshot, we’ve configured the SMTP Server to allow connections from two of our SharePoint servers.

Next, we’ll also ensure that only our two systems are allowed to relay messages through the SMTP server, which is accomplished by clicking on the “Connection” button on the same “Access” tab of the server properties. Note that we have the same two IP addresses listed, allowing only those two machines to relay:


From here, we need to configure the Office 365 mailbox username/password that the SMTP Server will use when sending messages. This is configured in the “Delivery” tab, using the “Outbound Security” button. Be sure to enter valid credentials for your Office 365 user, and if it’s a newly-created user make note that you’ll need to change the initial password on first login. If you don’t do this, mail will not send despite your best efforts!


Next we need to tell the server to use TCP port 587 when attempting to connect to Office 365, which is set in the “Outbound Connections” option of the “Delivery” tab:


Lastly, we need to specify which server to send mail through, and we do this by clicking the “Advanced” button on the “Delivery” tab. Be sure to specify the smart host as and clear the option to “Attempt direct delivery before sending to smart host”: this will ensure that all outbound mail will be sent via Office 365:


Configure Outgoing E-Mail Settings in SharePoint

Finally, we need to let SharePoint know about our new SMTP Server, which is done via Central Administration > System Settings > Outbound E-Mail Settings, as pictured below. Note that I’ve blurred out the values to protect the innocent, but you need to be certain to specify the servername, and your Office 365 mailbox user in the From address.


At this point, we’re ready to test our configuration and we’ll use PowerShell on the SharePoint server to do so. This way we can be sure that each component in our configuration is working, from the SharePoint settings through to the Office 365 mailbox. Open a SharePoint Management Shell and run the following PowerShell snippet:

$sdo = new-object System.collections.specialized.stringdictionary $sdo.add("to","") $sdo.add("from","") $sdo.add("Subject","Test message from SharePoint") $web = get-spweb "https://intranet" $messagebody = "This is a test message from SharePoint on-prem" [Microsoft.SharePoint.Utilities.SPUtility]::SendEmail($web,$sdo,$messagebody)

The output of the command will return “True” (and you’ll receive an email message) if it was successful; “False” indicates that something has gone wrong and the message was not delivered.

When things go wrong

In our experience, there are a few items that you’ll want to verify if outbound email is not flowing as expected, including:

  • the SMTP Server service is set to “Manual” start by default; be sure to change this to “Automatic” so that the service starts upon a reboot of your server
  • the Windows Server may require a server certificate in order for TLS to be used; this will generate an error in the Event Log and be evidenced by the SMTP Server Properties “Secure Communication” section of the “Access” tab indicating that no certificate can be found for TLS


E-mail is still a critical communication method in today’s business world, and moving email services to the cloud is more common than ever. We can still send email from an on-premises SharePoint server via Office 365 by setting up a local relay and sending mail from an Office 365 mail-enabled user.

Creating a Feature for the Site Actions Menu in SharePoint 2010


You can add a custom menu item to the default Site Actions menu in Microsoft Windows SharePoint Services by creating a Feature with a CustomAction element. In this way, you can add custom commands to the default SharePoint user interface. These commands are available to users as they move between pages on a SharePoint site. When you create a Site Actions menu item, you can configure it to redirect the user to any URL. For example, you can redirect the user to another Web site. You can also redirect users to a custom application page that allows them either to see a custom display of data, or to perform custom operations on the content within the current site.

Code It

  1. Create a new Project in VS 2010 and under SharePoint (left) select Empty Project.
  2. Now enter the url of your SharePoint site for debugging and select deploy as a farm solution.
  3. Now, once you have the project open, right click on the Feature folder and Add a new feature.
  4. SharePoint automatically adds a feature and names it as Feature1. You can however change the feature name to something like CustomActionFetaure.
  5. With this you will have a feature designer opened in front of you set the Title description and scope of the feature.
  6. Now right click on the Project and add a new Item. In the Add New Item dialog, select Empty Element to create a blank element file.
  7. Add the below Code to the element.xml file.

    <?xml version="1.0" encoding="utf-8"?>
    <Elements xmlns="">
    Rights="ViewListItems,ManageAlerts" Title="Manage Content and Structure" Description="Reorganize content and structure in this site collection.">
    <UrlAction Url="~site/_layouts/sitemanager.aspx"/>

  8. Build the Project. Open the feature.xml file and verify that if contains the reference to the element.xml file.
  9. Now Deploy the wsp and activate the feature in your site.

Read It

When you create a CustomAction element, you must add an inner UrlAction element that contains a Url attribute. When you redirect the user to an application page, such as SiteManager.aspx, you must consider whether you want the application page to run inside the context of the current site or the current site collection. In the following example, the dynamic token ~site is added to the beginning of the URL. When Windows SharePoint Services parses this CustomAction element and creates the menu item, it replaces ~site with the actual URL of the current site.


The key to security trimming your custom action is the Rights attribute. This attribute allows you to specify SharePoint permissions that the user must have for the action to be visible. This can be a comma delimited list. For example:


When more than one value is specified, the set of rights are treated with an AND. This means the user must have all of the specified rights for it to be visible. Here is a list of the valid Microsoft.SharePoint.SPBasePermissions you could use:

Also, When you create the element for a custom menu item in the Site Actions menu, you have the option to configure it so that it is shown only to users who have administrative permissions. Note in the following example the addition of a new attribute named RequireSiteAdministrator.


When you add the RequireSiteAdministrator attribute, Windows SharePoint Services does not show the menu item to users who do not have administrative permissions. For a CustomAction element in a Feature that is scoped at the site-collection level, the menu item appears only for the site collection owner or administrator. For a CustomAction element in a Feature that is scoped at the site level, the menu item appears only to those who have administrative permissions within the current site.



Related Link: