SharePoint Styling

Excuse the absence blog lovers, I have been busy setting up my own consultancy, working through my masters and preparing for another more tougher obstacle mud run, and enjoying the warmer weather.

 

Recently I have been trying to get a background image to display on a content area wiki page in SharePoint 2010, so without making changes to the master page I used a Content Editor Web Part, and pointed it to a text file in my Site Assets.

 

Using F12 I managed to find the exact element to style: .ms-rte-layoutszone-inner being the new plaything produced some of this magic:

.ms-rte-layoutszone-inner {
BACKGROUND-IMAGE: url(http://yoursite/SiteAssets/Images/background.jpg);

But the image didn’t scale well. Adding this displayed the whole image on the required area only on Chrome and Firefox:


background-size: 100% 100%;

The above CSS doesn’t work for me in Any Internet Explorer, even though research points to its support for browsers after 9, and mine is IE11.  (Blast you Microsoft!)

 

I did find a workaround though, adding some of this to the potion:

 

background-size: cover; filter: progid:DXImageTransform.Microsoft.AlphaImageLoader( src=’http://yoursite/SiteAssets/Images/background.jpg’,
sizingMethod=’scale’);
This uses a filter to scale the image to fit in the required area, and gets IE to behave like the other browsers.

That’s all, over and out.

Advertisements

Free Books

Another large collection of Free Microsoft eBooks and Resource Kits for you, including: SharePoint 2013, Office 2013, Office 365, Duet 2.0, Azure, Cloud, Windows Phone, Lync, Dynamics CRM, and more….

 Freebies:

 

http://blogs.msdn.com/b/mssmallbiz/archive/2012/07/30/another-large-collection-of-free-microsoft-ebooks-and-resource-kits-for-you-including-sharepoint-2013-office-2013-office-365-duet-2-0-azure-cloud-windows-phone-lync-dynamics-crm-and-more.aspx

The Trouble with Saving a Site as a Template, Office 365 Tricks

Oh how temperamental SharePoint can beat times. Here’s a quick tip.

Lets say you have a neat little Office 365 site collection you have customised, without activating publishing features, you have added some free third party apps from the SharePoint store, say the twitter app or something similar. Then you want to save this as a template, and you go to the usual site settings location and the beast isn’t there, and it was there the other day.

To troubleshoot, you will probably first remove as many customisations as you can, I’d recommend starting with the twitter app. Some third party apps cannot be saved in template, and good ol’ SharePoint doesn’t exactly tell us why we can’t do certain things. So you’ve removed the twitter app, but still the link is not available. Don’t go and reset everything without checking the site options parameter in SharePoint Designer.

The site has a parameter SaveSiteAsATemplateEnabled that is set to true until you do something (adding the twitter app) to make it switch to false. When you remove the twitter app, you would expect the paramater to change back to true. Wrong! It doesn’t automatically do this.

Open the site in SharePoint Designer, in the home page, Click on “Site Options”, you will get prompt, In the “Parameters”  Tab, you can find “SaveSiteAsTempalteEnabled”, set it to true.

 

Apply your change and refresh the site. You will be able to see the link to save the site as a template. If you still cannot save it as a template, the error message might be a little more informative as to why. Just remove the other offending items and check the parameter, and go for it again.

This is your captain speaking…Over and out

Active Directory, Azure Active Directory and Office 365

Apologies for the absence, I am engaged in a Masters degree as well as my SharePoint Career and being a good mummy! The pressure is on! And I’ve got another Nuts challenge 1st of March. I now realise why I was so happy to be done with my first degree….The requirement for prefect references has come along way since 2006!

I have a new client who has a requirement to move their current Java based intranet to SharePoint online, specifically Office 365.  They have Active Directory (on premise) already in place and do not want to change this as they have other application which are dependant on it. They also have Azure Active Directory (AAD) in place for other application so my solution will need to include these elements. My first question was why they needed AAD as Office 365 can work perfectly without it. Answer is they have several other Cloud applications that require authentication through AAD so this must be used. I needed to do some research into using an on premise Active Directory with AAD and Office 365, to see if they could mesh well together. Someone told me that the primary AD controller would have to be moved to Azure.

My research suggests that the on premise AD works very well with AAD (Azure AD) managing credentials for O365. My question to them would be why they needed it in the first place as O365 and on premise AD will work perfectly well with O365.  To hazard a guess would  be because they have several different types of credentials per user, e.g. Windows Live Account as well as the organisational account. I have both of these for Uni, the windows live account allows me to log on to OWA and access library services. The Organisational account is for when I’m logged in to the online portal or the desktop anywhere application (replicating conditions as if I were on campus)

My understanding of it is as follows:

What Microsoft have done is taken Active Directory, a widely deployed, enterprise-grade identity management solution, and made it operate in the cloud as a multitenant service with Internet scale, high availability, and integrated disaster recovery. You are able to have your AD on premise for all domains. Then you can use Windows Azure Active Directory to give users single sign-on to Software as a Service (SaaS) applications, O365 included. Applications running in the cloud or on-premises can use Windows Azure Active Directory Access Control to let users log in using identities from Facebook, Google, Microsoft, and other identity providers. To support this, Microsoft makes it easy to “connect” Windows Azure Active Directory with an existing directory. At the technical level, organizations can enable identity federation and directory synchronization between an existing Active Directory deployment and Windows Azure Active Directory.

When an organization does this, its Active Directory is, in a sense, stretching over both an on-premises and a cloud deployment. The ability for Active Directory to operate across both on-premises and cloud deployments in a hybrid mode enables an organization to easily take advantage of new cloud-based platforms and SaaS applications, while all of its existing identity management processes and application integration can continue unaffected.

In addition, being able to operate in this hybrid mode is critical for some organizations because of business or regulatory requirements that mandate that certain critical information, such as passwords, be maintained in on-premises servers.

If you don’t have your own on premise Active Directory, and you sign up for Office 365, Microsoft automatically create a new Windows Azure Active Directory that is associated with the Office 365 account. No action is required on the part of the individual signing up. This is the most simple approach, involving on premise AD is a more hybrid deployment.

In the diagram above, an organization can federate Windows Server Active Directory with Windows Azure Active Directory to give its users single sign-on to SaaS applications. In this scenario, a user at organization B wishes to access a SaaS application. Before she does this, the organization’s directory administrators must establish a federation relationship with Windows Azure AD using AD FS, as the figure shows. Those admins must also configure data synchronization between the organization’s on-premises Windows Server AD and Windows Azure AD. This automatically copies user and group information from the on-premises directory to Windows Azure AD. Notice what this allows: In effect, the organization is extending its on-premises directory into the cloud. Combining Windows Server AD and Windows Azure AD in this way gives the organization a directory service that can be managed as a single entity, while still having a footprint both on-premises and in the cloud.

To use Windows Azure AD, the user first logs in to her on-premises Active Directory domain as usual (step 1). When she tries to access the SaaS application (step 2), the federation process results in Windows Azure AD issuing her a token for this application (step 3). As before, this token contains information that identifies the user, and it’s digitally signed by Windows Azure AD. This token is then sent to the SaaS application (step 4), which validates the token’s signature and uses its contents (step 5). And is in the previous scenario, the SaaS application can use the Graph API to learn more about this user if necessary (step 6).

Today, Windows Azure AD isn’t a complete replacement for on-premises Windows Server AD. As already mentioned, the cloud directory has a much simpler schema, and it’s also missing things such as group policy, the ability to store information about machines, and support for LDAP. (In fact, a Windows machine can’t be configured to let users log in to it using nothing but Windows Azure AD – this isn’t a supported scenario.) Instead, the initial goals of Windows Azure AD include letting enterprise users access applications in the cloud without maintaining a separate login and freeing on-premises directory administrators from manually synchronizing their on-premises directory with every SaaS application their organization uses. Over time, however, expect this cloud directory service to address a wider range of scenarios.

Since 2011 Microsoft have enhanced Windows Azure Active Directory by adding new, Internet-focused connectivity, mobility, and collaboration capabilities that offer value to applications running anywhere and on any platform. This includes applications running on mobile devices like iPhone, cloud platforms like Amazon Web Services, and technologies like Java. So it doesn’t only have to be Microsoft technologies it utilises, it can be multi-platform.

Azure Active Directory Access Control

Windows Azure Active Directory (WAAD/ AAD) can give an organization’s users single sign-on to multiple SaaS applications, for example. But identity technologies in the cloud can also be used in other ways.

Suppose, for instance, that an application wishes to let its users log in using tokens issued by multiple identity providers (IdPs). Lots of different identity providers exist today, including Facebook, Google, Microsoft, and others, and applications frequently let users sign in using one of these identities. Why should an application bother to maintain its own list of users and passwords when it can instead rely on identities that already exist? Accepting existing identities makes life simpler both for users, who have one less username and password to remember, and for the people who create the application, who no longer need to maintain their own lists of usernames and passwords.

But while every identity provider issues some kind of token, those tokens aren’t standard – each IdP has its own format. Furthermore, the information in those tokens also isn’t standard. An application that wishes to accept tokens issued by, say, Facebook, Google, and Microsoft is faced with the challenge of writing unique code to handle each of these different formats.

But why do this? Why not instead create an intermediary that can generate a single token format with a common representation of identity information? This approach would make life simpler for the developers who create applications, since they now need to handle only one kind of token. Windows Azure Active Directory Access Control does exactly this, providing an intermediary in the cloud for working with diverse tokens.

The image above shows how Windows Azure Active Directory Access Control makes it easier for applications to accept identity tokens issued by different identity providers.The process begins when a user attempts to access the application from a browser. The application redirects her to an IdP of her choice (and that the application also trusts). She authenticates herself to this IdP, such as by entering a username and password (step 1), and the IdP returns a token containing information about her (step 2).As the image shows, Access Control supports a range of different cloud-based IdPs, including accounts created by Google, Yahoo, Facebook, Microsoft (formerly known as Windows Live ID), and any OpenID provider. It also supports identifies created using Windows Azure Active Directory and, through federation with AD FS, Windows Server Active Directory. The goal is to cover the most commonly used identities today, whether they’re issued by IdPs in the cloud or on-premises.

Once the user’s browser has an IdP token from her chosen IdP, it sends this token to Access Control (step 3). Access Control validates the token, making sure that it really was issued by this IdP, then creates a new token according to the rules that have been defined for this application. Like Windows Azure Active Directory, Access Control is a multi-tenant service, but the tenants are applications rather than customer organizations. Each application can get its own namespace, as the figure shows, and can define various rules about authorization and more.These rules let each application’s administrator define how tokens from various IdPs should be transformed into an Access Control token. For example, if different IdPs use different types for representing usernames, Access Control rules can transform all of these into a common username type. Access Control then sends this new token back to the browser (step 4), which submits it to the application (step 5). Once it has the Access Control token, the application verifies that this token really was issued by Access Control, then uses the information it contains (step 6). While this process might seem a little complicated, it actually makes life significantly simpler for the creator of the application. Rather than handle diverse tokens containing different information, the application can accept identities issued by multiple identity providers while still receiving only a single token with familiar information. Also, rather than require each application to be configured to trust various IdPs, these trust relationships are instead maintained by Access Control – an application need only trust it. It’s worth pointing out that nothing about Access Control is tied to Windows – it could just as well be used by a Linux application that accepted only Google and Facebook identities. And even though Access Control is part of the Windows Azure Active Directory family, you can think of it as an entirely distinct service from what was described in the previous section. While both technologies work with identity, they address quite different problems (although Microsoft has said that it expects to integrate the two at some point).Working with identity is important in nearly every application. The goal of Access Control is to make it easier for developers to create applications that accept identities from diverse identity providers. By putting this service in the cloud, Microsoft has made it available to any application running on any platform.

There is no requirement for a Primary AD controller to be moved to Azure, you just ‘connect’ and sync up.

References

http://en.share-gate.com/blog/migrate-to-office-365-configure-sharepoint-to-use-active-directory

http://www.windowsazure.com/en-us/documentation/articles/fundamentals-identity/

http://blogs.msdn.com/b/windowsazure/archive/2012/07/12/announcing-the-developer-preview-of-windows-azure-active-directory.aspx

http://blogs.msdn.com/b/windowsazure/archive/2012/05/23/reimagining-active-directory-for-the-social-enterprise-part-1.aspx

http://redmondmag.com/articles/2013/07/01/cloud-identity.aspx

http://betanews.com/2013/07/12/active-directory-as-a-service-azure-intune-hinting-at-a-cloud-hosted-ad-future/

Setting it up involves running a few PowerShell commands to set up a trust between ADFS and AAD. SSO needs to be implemented and the domain must be a top level domain. Full steps here http://technet.microsoft.com/en-us/library/jj205461

This is the only recommended implemented approach I have found for this hybrid deployment. If anyone can highlight other approaches I would be most interested to know.

Over and Out

‘Free’ Tools for Office 365

I’ve been on the lookout for tools to manage O365 implementations and found MessageOps offer some free tools for signed up clients. Its easy and free:

http://www.messageops.com/software/office-365-tools-and-utilities

Check their offerings…

Customizing a Survey

You boffs out there will recognize the pains of providing a quick POC for a customer requirement without developing a fully fledged solution. Ok so here goes. You wanna provide customization to a survey without going full code. For example, in my requirement (Office 365 Implementation), I wanted to add a ‘response’ column to a survey which does not behave like a normal list (naughty naughty!) . This column would store a response to the answer to the survey by means of a workflow on that survey. (There was only one question in the survey as the answers needed to be anonymous and this is near impossible without full code to any list because of the default columns: Created by and Modified by). So the user answers that one question, the workflow kicks off to collect feedback from the manager or approved person who can respond to it, and then the workflow fills the response column of the survey with the response . Simples hey? lol

Ok So here are the cheats for customizing a survey:

Create New View:

  • Open the new view page of any list in your SharePoint site, and copy the URL to a notepad.
  • Open  survey settings page, and from the URL copy the List ID. (List=%7Bxxxxxxxx%2Dxxxx%2Dxxxx%2Dxxxx%2Dxxxxxxxxxxxx%7D).
  • Replace the list name to the last of the URL with the survey list name.

Copy the modified URL to a new browser window, and you are done, you will be now in the ‘Create View’ page of your Survey List. Create the view as you wish here……….

Create A New Column:

Same the way you did for survey view, copy the new column page url (/_layouts/fldNew.aspx?ListID)

  • Replace the ListID with the survey list ID and you are done.

 

Modify View:

  • In order to perform the modify view of the newly created view as per the steps above, just add your list as a webpart to any SharePoint page.
  • In the modify shared webpart option, select the view which you want to edit in the Selected View and  select the option ‘Edit the current view’.

As with all hacks, save a copy in case you break anything and regularly back up your servers. If you’re on Office 365, Microsoft got your back!

 

Update

Sorry for the delay but its been one hell of a summer her in the British Isles and I have been enjoying it to the max! I’m also preparing for my architecture exams and starting my Masters in January, so blogging has taken a back seat. My daddy always tells me to improve the mind you must also improve the body, so I trained for 4 months for the nuts challenge in August The Nuts Challenge and came 59th (out of around 1500). First ever run on a pro scale, I’m super proud of myself, but needless to say as with all new things for me, I am hooked and looking for the next challenge to fill my desire!

Onwards and upwards we go, all day everyday!!!

Muddy!

The hill that can kill!

Torture!