Configure automatic password change in SharePoint 2013 using PowerShell

SharePoint fellas!

I have a new tip for you.
My very best SharePoint buddy asked me today how to configure the Automatic password change using PowerShell, he could not find an answer anywhere…it was a good question…seems like the answer was missing and that was when I started to do some research.
I found nothing! Could be that I missed something, but Technet, Blogs, Forums, none had the answer…

The impressive Engine of a Boeing 787 – Dreamliner

After a lot of testing and failing, I managed to produce this working script:

*Must be executed in a PowerShell prompt running as administrator.
*If used in a .ps1 script file, you have to set the execution policy first.
*Replace the domain\accountname with an existing managed account.
*Change the values to valid values that you want to use.

# Set Automatic password change schedule

$SPManagedAccount = Get-SPManagedAccount -Identity “domain\accountname”

#Create a SPMonthlySchedule object and set default properties (as in the gui)
$SPSchedule = new-object Microsoft.SharePoint.SPMonthlySchedule
$SPSchedule.BeginDay = 7
$SPSchedule.EndDay = 7
$SPSchedule.BeginHour = 2
$SPSchedule.EndHour = 3
$SPSchedule.BeginMinute = 0
$SPSchedule.EndMinute = 0
$SPSchedule.beginsecond = 0
$SPSchedule.endsecond = 0

# Set the change schedule on the account
$SPManagedAccount.ChangeSchedule = $SPSchedule
$SPManagedAccount.DaysBeforeExpiryToChange = 2

# Properties not enabled in a default scenario in the GUI
$SPManagedAccount.EnableEmailBeforePasswordChange = $False
$SPManagedAccount.DaysBeforeChangeToEmail = 2

# Enable and make the change
$SPManagedAccount.AutomaticChange = $True
$SPManagedAccount.Update()

Done!

In my environment, it looks like this:

After successfulle updating the Managed Account with the automatic update Schedule, I just typed in

$SPManagedAccount

and hit enter, that gives you the most common properties
If you want to see the entire Schedule with details, type in:

$SPManagedAccount | ft ChangeSchedule

Then you get this:

Thats it, a Schedule has been set!

If you want to use the GUI in central administration to find out what values to set, enable the Automatic Password change on any managed account, than set the values you want in the graphical user interface. Save them by clicking OK.
Next you run the following in your PowerShell prompt:
$SPTemplateManagedAccount = Get-SPManagedAccount “corp\sp10search”
$SPTemplateSchedule = $SPTemplateManagedAccount.ChangeSchedule
$SPTemplateSchedule
This will produce a list looking like this:
BeginDay    : 7
EndDay      : 7
Description : Monthly
BeginHour   : 2
EndHour     : 3
BeginMinute : 0
EndMinute   : 0
BeginSecond : 0
EndSecond   : 0
Use the values in the list in your script and you will have identical values set.

Note: If you want to have a Daily Schedule instead of Monthly like in my example, you will have to modify the script to create a Microsoft.SharePoint.SPDailySchedule object instead.
If you do that, you will also have to remove the lines setting the BeginDay and EndDay values, they are not used in a Daily Schedule object.

Good luck!

References:

Configure automatic password change in SharePoint 2013 (GUI version only)
http://technet.microsoft.com/en-us/library/ff724280.aspx

Plan automatic password change in SharePoint 2013
http://technet.microsoft.com/en-us/library/ff724278.aspx

Thanks to:

Mattias Gutke at CAG. He asked the question…

___________________________________________________________________________________________________

Enjoy!

Regards

Twitter | Technet Profile | LinkedIn

A guide to Alternate Access Mappings Basics in SharePoint 2013

Alternate Access Mapping Basics in SharePoint 2013

(This post is in its entirety valid for SharePoint 2010 as well)

Explains how you should look at Alternate Access Mappings – left to right.
Alternate Access Mappings is something that most SharePoint engineers or administrators struggles with. More often than not, you get it right in the end but we are not really sure why it works or if it really works the way we want it to.
This, is my attempt to make it easy to understand.

Note: This is part 1 in a series, the next part will show how to configure DNS and a simple scenario adding a new NetBIOS name as URL to a Web Application.

Note: For the complete guide, with DNS steps and 4 different scenarios including https, download the free Whitepaper from TechNet: The final guide to Alternate Access Mappings

In order to make AAMs simpler to understand, look at it a bit differently, start with this simple table:

Left area            Internal URL’s
Right area          Public URL’s with a zone
Middle area        Zones, is what connects Internal URL’s to Public URL’s, many to one.

Internal URL redirects or transforms to a Public URL, from left, to right. The URL on the left, is what you enter in the address field in your browser, the Public URL on the right is what you will see once there, this goes for visible and invisible links as well.
Internal URL format: Protocol + URL (+non default port)

Public URL is the address of the Web Application for one of the five zones available. The ‘Default’ must be filled out and has some special properties/uses, the other four are optional. You can only have five Public URL’s per Web Application.
This is the URL that the browser will be redirected to in the end.
Public URL format: Protocol + URL (+non default port)

Zone is a label representing a Public URL, the zone is used to ‘connect’ an Internal URL to a Public URL. The zone names has no relation what so ever with the four Internet Explorer security zones (Internet, Local Intranet, Trusted sites and Restricted sites) and could just as easily been named 1,2,3,4 and 5. A zone can also represent an authentication provider.
Zones: Default, Intranet, Internet, Custom, Extranet

Example:

Note: Based on the Zone selected for every Internal URL, they will be connected to a Public URL.

From left – to right…
The zones might as well be represented by numbers:

Note: Try to always use the most used URL as the default Public URL. This is what will be used by other services, like crawl and in certain other links.

Translated to SharePoint GUI, this same setup would look like this:

Note: Filtered on this Web Applications Alternate Access Mapping Collection only.
Same Alternate Access Mappings as in the Example table above.

You will see that if you click on any of the ‘Internal URLs’ that you can select zone, and with the zone, the Public URL it will be connected to:

In addition to the actual Alternate Access Mapping in SharePoint Central Administration, you also have to add a Binding in IIS, contrary to what many believe, except for the initial hostheader when you create the web application, SharePoint does not do that for you, so you have to do it manually.
The example above would show up in IIS Bindings like this:

As you can see, in IIS 8.0 and Windows Server 2012, the https binding does show up as a hostname, in IIS 7.5 and Windows Server 2008 R2, the hostname is determined by the name configured in certificate used when adding that binding and hidden in this view.

That’s it! When you have configured your AAM’s and Bindings correctly, given that you have name resolution and IP addresses in order and connectivity from the client to the server(s) and all other aspects in order, you can now start to use the URL’s you want.

_________________________________________________________

Enjoy!

Regards

Twitter | Technet Profile | LinkedIn

How to: Change the Distributed Cache Service managed account 2013

Hi friends.

When you get the annoying pink marker in CA and one of the issues it warns you about, is that ‘the farm account should not be used for other services’ In my case, the scripted install had set the ‘Distributed Cache Service (Windows Service)’ to use the farm account as managed account. As the 2013 Central Admin is (or tries to be) helpful, it gives you the direct link to the: ‘Security’ – ‘General Security’ – ‘Configure Service Accounts’ and tells you to change it there.

To fix it, just click the link, find the service in the dropdown and select another Managed account in the lower dropdown. Then click ok…..but nooo…that one wont fly.
Changing the service account on this service cannot be done this way and has to be done using PowerShell…thats what you get back.

Well…after some short researching I found this to work ok: (first load the snapin, add-pssnapin microsoft.sharepoint.powershell)

$farm = Get-SPFarm
$cacheService = $farm.Services | where {$_.Name -eq “AppFabricCachingService”}
$accnt = Get-SPManagedAccount -Identity <domain\user>
$cacheService.ProcessIdentity.CurrentIdentityType = “SpecificUser”
$cacheService.ProcessIdentity.ManagedAccount = $accnt
$cacheService.ProcessIdentity.Update()
$cacheService.ProcessIdentity.Deploy()

(Where <domain\user> is the domain name and user name of the managed account you want to use instead.)

Note: Beware of the doublequotes if you copy the code…

Wait until it has run, then you will find that the service has a new managed account.
Go back to the Health Analyzer report page and remove the alert.

More on the Distributed Cache:
Manage the Distributed Cache service in SharePoint Server 2013
http://technet.microsoft.com/en-us/library/jj219613(v=office.15).aspx#changesvcacct

_________________________________________________________

Enjoy!

Regards

Twitter | Technet Profile | LinkedIn