Azure will help you run a SharePoint farm that you can access any browser and Remote Desktop, versus having to lug around a super-beefy laptop. This cloud-first strategy also allows me to test various versions of a product or multiple products without having to worry about hardware requirements or storage space on my laptop.

Here are some tips when starting the process of creating Azure VMs for SharePoint:

• Create a different subnet for SQL and App servers. I created three subnets, one for DNS, one for SQL and one for Apps (where WFEs and APP servers live). This is not a requirement, but is a good way to separate roles and keep IPs in a certain subnet.
• Remember that the first 3 IP addresses are kept for the host in an Azure VM so do not try to reserve an .1, .2, or .3 address. It will cause an error at best.
• Change the settings in Edge/Internet Explorer so you can log into your MSDN Subscription and download files or use a blob storage account to keep your binaries in one location.
• To enable file downloads:

• To enable scripting to login to your MSDN account:

• If you have access issues from other VMs, temporarily shut off Windows Firewall on servers, get connectivity and then go back and troubleshoot public, private files. Most recommend that you can shut off Windows Firewall if you are using VMs for test boxes only. NEVER shut off Windows Firewall for staging or production servers.  Search for the “Windows Firewall with Advanced Security” shortcut.
• Then click the “Windows Firewall Properties” link and turn off the appropriate profiles to temporarily disable. If you have access to other VMs and can add them to your domain, then this step is not needed.
• Set up the Domain Controller VM first.
• Build a process with on Azure PowerShell scripts to shutdown your VMs when not in use. This will save you money or credit.
• Find a mobile application that will help you shutdown your VM’s if you do not have access to another device. Each platform has their own and it comes in handy when you are not able to log in to a PC to make this happen. There are multiple on each mobile platform (Windows Phone, iOS and Android)
• Set a static IP address for your VM by using Set-AzureStaticVNetIP, here’s a reference… http://windowsitpro.com/windows-azure/set-azure-vm-static-ip-address
• Configure an endpoint to remotely access SharePoint URL remotely.
  • Select the VM hosting the CA/WFE role, then go to Endpoints > Add an endpoint with a public and private port of 80. You can also add a custom domain for the farm, if you choose.
  
  • Add a Alternate Access Mapping (Central Administration > System Settings > Configure alternate access mappings), usually the name of your cloud service with a .cloudapp.net domain name for the “Internet” zone. This action will allow SharePoint accept requests for this URL.
• Setting up your SharePoint farm depends on your version and your requirements, so from here it’s a matter of planning how to install SharePoint the way you need to test your system.

I have found selecting “D” series Virtual Machines will work well, but prefer to have more memory than recommended. For a domain controller and WFEs, I use a D2 with 2 cores and 7GB of memory. For SQL. a D3 with 4 cores and 14GB of memory do the trick.

This will get your started with Azure and SharePoint.

To enable or review these settings, go to “Settings” > “Site Settings” > “User and Permissions” and click “Access Request Settings”. In the “Access Request Settings” dialog box, select the check box next to “Allow access requests” then provide an email address of the individual you’d like to manage this feature.

If a site has multiple groups with the same permission levels (Owners, Members and Viewers) but there is not an assigned default group, then you will see the problem where access requests will either not display for the impacted user or an owner will not be able to approve requests.

Here’s a Windows PowerShell script to change each of the groups for a site so that each is identified as the default group for Members, Owners and Visitors

You’ll need to a the “Microsoft.SharePoint.PowerShell” add-in at the top of the script to get the SharePoint references.

#Members Group
$web = Get-SPWeb "https://sharepoint.contoso.com"
$groupToMakeDefaultMembersGroup = $web.Groups | ? { $_.Name -eq "Team Site Members" }
$web.AssociatedMemberGroup = $groupToMakeDefaultMembersGroup
$web.Update()

#Owners Group
$web = Get-SPWeb "https://sharepoint.contoso.com"
$groupToMakeDefaultOwnersGroup = $web.Groups | ? { $_.Name -eq "Team Site Owners" }
$web.AssociatedOwnerGroup = $groupToMakeDefaultOwnersGroup
$web.Update()

#Visitors Group
$web = Get-SPWeb "https://sharepoint.contoso.com"
$groupToMakeDefaultVisitorsGroup = $web.Groups | ? { $_.Name -eq "Team Site Visitors" }
$web.AssociatedVisitorGroup = $groupToMakeDefaultMembersGroup
$web.Update()

#Enable Access Requests after it was disabled
$web.RequestAccessEmail = "user@mydomain.com"
$web.Update()

If you turn off the feature, you will can re-enable the feature by adding an email address to the “RequestAccessEmail” property.

Hope this helps solving the problem around assigning default groups and enabling the Request Access feature in SharePoint 2013.

I am still in the process of reproducing the issue to see what caused this value to cause a problem within the farm, but when you see where the OWA servers cannot render documents, this would be a good start to review. I have provided a link to the complete instructions on how to configure Office Web Apps so that you can fully understand some of the requirements needed to make OWA perform as you expect.

Remember, Internal HTTP/HTTPS = NetBIOS, External HTTP/HTTPS = FQDN, very important in the configuration of this SharePoint component. Also, as you will see in Steve’s article, all this is done through Windows PowerShell and is not exposed through a UI.

Reference to process to “Configuring Office Web Apps” by Steve Peschka

Here’s the screen, we all have seen it before and might know why it’s there, or might not and do not know how to fix problems. There are a couple of banners colors that will display; Red or Yellow. Red is bad, yellow might be bad and still need to be viewed (and fixed) quickly. In most cases, the red warnings are rules that impact direct health or security of for the production environment.

When you seen the SP Health Analyzer banner with this type of information, click the “View these issues” link to see what’s going on.

In this case, I have a test environment on an external drive that I allotted only 60GB (not in compliance with Microsoft’s Hardware and Software Boundaries) and now I’m being told that my drives are running out of space (see below).

From this message, I can see the category (Availability), which servers are failing, which service told SharePoint about the issue and when it was first reported.

Rules within Health Analyzer

There are multiple categories of rules that you can use or disable, control the schedule or allow the process to automatically repair. It’s important to understand what they do and how they can impact the health of your SharePoint environment. Running out of space is something that SharePoint cannot fix itself, so you’ll have to develop a plan of attack to ensure these architectural items are addressed.

The rules defined in SharePoint cover a broad range and in the following cases identify security and performance issues that can plague various use cases. Review them and understand what the rules are evaluating to keep your environment strong.

Editing a Health Analyzer Rule Definition

Once you receive this screen, there a couple ways to approach the way you resolve the identified issues. Let’s talk about the fields in the screens and see how we can modify the rules to our needs.

Title: Text that will be shown when the rule is implemented.
Scope: This can be “All Servers” or “Any Servers”, as the rule shows, it will try all servers with a specific server or any server on the first available server. 
Schedule: Choices are “Hourly”, “Daily”, “Weekly”, “Monthly” or “OnDemandOnly”.
Enabled: This rule is a “Yes” or “No” option, and is the ideal way to manage rules. I would recommend against explicitly deleting rules.
Repair Automatically: SharePoint will attempt to fix the issue automatically if this is selected. My recommendation is to deselect this to ensure you understand what is being done to fix the problem.
Version: Version number.

In the next article, we’ll talk about creating your own rule so that you or your team will be alerted if your environment is hitting a rule that you put in place to monitor a best practice or standard you have in your farm.

Recently, I was asked exactly how the Site Confirmation and Deletion feature works in SharePoint? Does the timer restart when a user visits the site? Does the feature look at the some field and then reset the value in a service? It was a simple question that made me think about how the process worked from an Administrator point-of-view.

The simple answer is that once a user adds content to a site, a field in a content database is updated and then when a timer job is run, it will review that field and notify site owners appropriately to ensure that they are notified that their site is on “the chopping block”. Based on your configuration, it will notify you after 90 days (by default) of site collection creation or confirmed use. You can change the amount of notifications sent or you can automatically delete the site collection if use is not confirmed after 28 notices.

To access this feature, go to Central Administration > Site Collections > Site Use Confirm and Deletion option.

Some administrators or business users do not like to use this feature, but you can see that you have to make a very big effort to not confirm your site’s usage before it magically vanish. Also, this can provide a great deal of efficiency for the removal of sites that are just not used anymore.

That’s the Executive Summary of how it works, let look at the details.

There are three database fields that play a part in the process and they are:

• “DeadWebNotifyCount”
• “CertificationDate”
• “LastContentChange”

DeadWebNotifyCount and CertificationDate are used to keep track of the date that a site owner verifies the use of the site. These fields are reset when the user verifies usage through the email sent. Do not modify the values in the SharePoint database, as this is not supported by Microsoft. The LastContentChange field keeps record of the last time a document or list item (or any content) changes on the site. This feature does not use the last time a user visited the site, only when content changes.

This feature is misunderstood, but a very valuable tool to manage storage space and helps provide governance within your environment, use it or not, but keeping sites that are timely and relevant is always important and having a tool to help administrator’s is a plus.

Let’s start off the article by saying that I am a very big proponent of Microsoft’s SharePoint Designer (SPD) product because it allows end users, administrators, designers and developers the opportunity to make changes that can directly impact productivity without the introduction of managed code. That being said, there are some issues that come with providing the freedom to do what is needed to maintain a SharePoint site, especially if someone else is on the hook if a person deletes a site, rebrands a page or causes other acts of madness with SPD.

One of the great features of Microsoft SharePoint Server (MSS) 2010 is that as a Farm Administrator I can check a couple of boxes and access to my farm’s site with SPD and other types of changes is DENIED! But let’s try to be a little more open-minded than taking the easy way out and just shutting everyone out of the fun.

Before we look at the code, let’s figure out what we want to do. The options are as follows:

• Allow the use of SPD
• Allow Master Page editing
• Allow users to Revert from Template
• Show URL Structure

The following lines of code can help you implement one measure of Governance, and some sense of sanity, within your SharePoint farm.

The code above is reflected in the UI within SharePoint’s Central Administration:

Let me try to explain what each option allows you to limit. First we have to the ability to limit SPD. In this case, we’re allowing the site administrators to edit sites with SPD. This is also scoped at the SPSite level, as well. deselecting this option will deny users to make changes via SPD.

Next is the “Detach Pages from Site Template”, which allows users to create their own design based off a template. It’s the equivalent of copying a template so it can be available in a stand-alone fashion.

“Allow Site Collection Administrators to Customize Master Pages and Layout Pages” enables changes to be made to those specific pages. This would significantly impact branding if you let users change the Master Page at will.

Finally, we have the ability to let users see (and manage) URL Structure. Moving pages, see which folders and files exist are just some of the examples.

So the purpose of showing the images is not for the code, but to show the potential flexibility that you have within your farm to allow some site collection administrators access to the tools needed, or restrict the use of those same tools to others.

As far as the code, a developer could continue with this and develop a feature where an administrator could turn on or turn off access on each Site Collection (SPSite) as needed. I like the fact that this solution is flexible and helps you govern your environment and the choices can be tuned on an as-needed basis

Let’s start the process.

First, go to Central Administration, then Application Management > Web Applications > Manage Web Applications. Below is a list of my Web Applications that I can apply to my policy. Select “User Policy” for the appropriate Web App (I selected “SharePoint – 80”).

Before I start, the default users and permissions are listed below, but I want to add my own permission so that I can limit the creation of sub-sites for a specific user (and security group). I select the “Permission Policy” button, then I get this screen to create my own permission policy. Click “Add Permission Policy Level” to start the process.

The first screen I see to build my permission level asks me to create a Name and Description. The “Site Collection Administrator” and “Site Collection Auditor” provides a method to elevate permissions and let the user or group identified in this policy. As the creator of the permission level, there’s a granular control over what level of access I will let this group have in this web application.

After I select “Grant All”, I can go back in and change individual permissions. In this case, I have denied the ability to create subsites. This is a helpful permission level if you have users that constantly delete sites.

After I’ve finished, my permission level is available to be utilized in my web application.

When I finish, I am going back to click “Add Users”…

This screen will pop-up and now you can select a zone to restrict. In this case, I’m going to restrict all zones within this web application.

Then select a user (DEMO\price) and a Security Group (DEMO\SharePoint Admins) and apply the “Deny Site Creation” permission level. Notice that I could apply the “Account operates as System” bit and that will record actions as a system account versus an individual account.

I finish this and now I am ready to test by logging in a “DEMO\price” and then try to create a site by clicking “Site Actions”. If you notice the option is trimmed so that the user does not see the option.

I had to test this a couple times to make sure the permission level was acting as expected, but it works as advertised and now I can apply different policies for Lists, Libraries, Site Management, Personal View or Alert actions.

That’s pretty much it and I like this way to manage my policies instead of applying them across my entire web application because I can go back in and add another user or uncheck a box, or create a new permission level that only applies to another set of users.

Like anyone else who is trying to explain technical information, my goal is to be concise and accurate, so please leave comments, ask questions or email me to continue the conversation that we start here. I hope I do well and for you to enjoy and learn from my small contribution to this large Microsoft community.