Select Tags and then you add a name and a value for the tag. For example, Name: Start Value:

7:00AM and click save, then add another tag to stop, for example, Name: Stop Value: 5:00PM. Add the same Tags to all the computers you want to Start/Stop.

Copy the tag names and values in one note, you will need that information to configure the runbook.

Go to your Automation Account.

Click on Runbooks Gallery. If filter window appears just click ok.

7. Click on “Shutdown/Start VMs by tag”

Click on “Import”.

Type a Name to the Runbook and click ok:

Click on “Edit”:

11. Click on “Publish” and then click on “yes”

12. Click on “Schedule”

Click on Schedule, Create a new schedule, type a name and then configure the schedule as following image, you can make it recurring and selecting Week you can select only the desired days to start the VMs.

Click on “Create” (Screenshot on next page)

15. Click on “Parameters and run settings”

16. Add the Tag Name and Tag Value that you already added to the VM to Start. Example: TagName: Start TagValue:7:00AM.

17. Shutdown: if you select False then the VM will Start. If you select True the VM will stop.

Click OK.

19. Click “OK” again

The runbook is now created and It will start all the VMs that are tagged with the name and value you selected.

Now you just need to create the runbook to stop the VMs at desire time.

To create the runbook to stop the VM you just need to follow the same steps, but using the Tag Name and Value that you defined to Stop, for example: Tag Name: Stop Value: 5:00PM and Shutdown: True to stop the VM.

The advantage of use these runbooks is that if you need to add more VMs to start and stop, you just need to add the Tag Name and Value to the desired VM and it will be automatically added to the runbook scope.

Recently I had to upgrade SharePoint 2013 servers with September 2016 CU. Before we start talking anything about this make sure you have SharePoint 2013 SP1 is installed as this is a prerequisite for this CU.

September 2016 CU build number is 15.0.4859.1000. It fixed the issues described in the below articles.

If you are on track to make your SharePoint hybrid then I would highly recommend updating your farm with this CU as it has all the goodies required for a fast track hybrid install.

Always check the current SP/CU status before you start patching Sharepoint. I found that our server DB configuration was no compatible so had to fix that before moving forward. Below is a common error you might see at central admin->upgrade and migration -> DB upgrade status.

error: SharePoint 2013 Database is in compatibility range and upgrade is recommended

To Fix this issue, lunch SP management shell with farm admin account and run

” psconfig.exe -cmd upgrade -inplace b2b -wait ” Remember that this is a b2b upgrade and not a v2v. Which means if you are upgrading from one version of SP to other you will use ” psconfig.exe -cmd upgrade -inplace v2v -wait”. For RTM upgrades you will use b2b.

Before you take any other step MAKE SURE YOU HAVE ALL THE BACKUPS. In case CU messes something on the server there is no way to roll back. You have to rely on your backups only. Snapshots are life savers.

CU upgrade is a two-step process. First you run the CU exe and then you run the SharePoint configuration wizard.

Now that your current farm is all set we are ready to run the upgrade. Download the CU files on to your server from KB3118279

You need to download the files on all the servers in the farm. SharePoint CU should be installed on all the servers in the farm. Of course, you would not worry about the DB server at this point. The recommended order is to run on the server where the central admin is installed, then all other app servers and then all the WFE servers. I was able to proceed in this order with no issues. Once you copy over all the files, run the EXE. This will take a while maybe an hour or more. After installation is done then check status at upgrade and migration->check product and patch installation status. If there are no errors then you are good to move to other servers. Repeat the process on all other servers. After this process is done on all other servers then you are good to run configuration wizard. I use power shell for this. Get back to APP server where central admin is installed and run “https://www.microsoft.com/en-us/download/details.aspx?id=53802 . “psconfig.exe -cmd upgrade -inplace b2b -wait” .

If you run the confi upgrade without wait you might see ” Unable to create a Service Connection Point in the current Active Directory domain. ” error and upgrade will fail. In most places Network admins may not want to keep track of the SharePoint installation packages and you can just skip that part. But if you do keep then below steps may help

Start ADSI Edit on your domain controller. Expand System, Right click in the white area then choose New > Object…Create a container, Type the container name Microsoft SharePoint Products and press Finish, Run SharePoint Configuration Wizard again.

You have to run with on all the servers. Now go to upgrade and migration -> review DB status. Also, do “check upgrade status” and hopefully you will see a success message.

One of our SharePoint 2010 sites started throwing an error with correlation ID. This site has multiple user permissions.

The issue started occurring after a routine windows maintenance. so I figured this should not have happened due to code or DB issues. ULS logs also pointed out there was an issue with space but when I checked all the drives had enough free space. Though there was enough free space I did delete some old files as I have seen before in VM’s with SAM storage there could be some drive corruption and though it shows free space you will not be able to write any files to it. It did not help.

Next thing was to look into the error above. I googled it and read some articles talking about app pool permissions so I checked to make sure app pool account was good. This account was not changed since the site was created and it was active.

Next, I restarted the app pool which will recycle the IIS cache and that did the trick.

Before any major release, it is fun to create excitement among users. It will also encourage users to look forward to the new product. Recently I used a timer to keep up the excitement of a new site we were going to release. I have used SharePoint script editor webpart and embedded this script which will show a timer countdown on your page.

I came across this question a lot. Simple answer would be that there are times when you need to modify and some times you don’t have to. If you are an experienced developer and know the best practices, you can modify. If not stick with html as it is much easier to handle. Recently on SharePoint stack exchange I read some one asking how to modify seattle.master and whether he should modify or not. Below is the best answer.

Answer:

If you will bear with my I will first answer a question you did not ask, and then I’ll get to your actual question.

What did you modify exactly, the file on disk or on the web site (through SharePoint Designer or a mapped drive) ?

If you have modified the file on disk, you should copy your changes some place safe (for later, see next) and immediately revert to the original file. Any modification to SharePoint’s OOTB files are bound to a) cause loads of problems and b) be overwritten by future updates. By modifying the file on disk you are effectively changing the master page for each and every existing site that uses that style. Most files you see in a web site are in fact links to the file on disk until they are customized(next paragraph).

If you have modified the file in the web site (in _catalogs/masterpage), in effect you have customized the file, that is you have detached it from its source definition on disk and created a local copy that now lives in the database, only for that site.

What a customized file means is: – You will need to re-apply those changes manually to any other site where you want it as they are all independent. This includes production, future sites, etc. – All of those sites, after you have modified them directly, will have their own independent copy of the file which are not related to one another so you will not be able to make mass updates to your branding.

If you have only one site at this time, you might think you are ok. But SharePoint has a tendency to grow…

If you are doing custom branding, the bare minimum would be to make a copy of seattle.master to a custom name, and work on that. That will avoid you the interference headaches with official updates and modifications to the standard master page (which you should keep as fallback should things go wrong).

Next, you should really consider a deployment package (e.g. a file on disk). Then when you create a new site, you just set it to use that master page (manually, through feature activation, at this point it does not matter). This way, all of your sites will still use an un-customized master page, meaning they will in fact all be references to the one on disk. This makes updates much easier and is the norm in enterprise settings. The same goes for your CSS and JS files.

You could have CSS and JS files in the _layout directory but for this you really want a deployment package, never drop files there manually.

And now, to specifically answer your original question:

The difference between the .master and .html pages is not that much, but you can view .html as preceding the .master. Some master pages do not have an associated .html page, but if you upload a .html file SharePoint will automatically create a .master. The latter is the one that is used in the end, with the .html being more of a “designer file” and is easier to work with for most HTML folks (has all the markup as comments, so you have fewer chances of wrecking the final ASPX markup).

So, if you have both, work on the .html file. If you have only the .master, work on that one. What you should avoid is uploading a .html file, then working on both the .master and .html files because every time you save the .html SharePoint will overwrite your .master. Once the .master is generated the .html is mostly ignored by the system.