Call Azure Function from Powershell

I was fooling around with Azure Functions and wanted to try calling a Webhook function from Powershell. I just wanted to test a simple function from Powershell

I kept getting an error saying that 'The underlying connection was closed: An unexpected error occurred on a send' when I used Invoke-RestMethod.

Turns out that for some reason, you have to force Powershell  on TLS 1.2

When I ran this command to do that -

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

it worked and I got my 200 OK response.

To reset, you can run this command -

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls

Hope this helps anyone out there struggling.

Thanks,
Soren

Powershell MA version 5.5.3.1309 released

Glad to announce that the Powershell MA has a new version out. It's has been a while since the last release since there has been no reports of bugs or any feature request lately, the previous version seems to be pretty stable.

This new version hasn't changed all that much and there are no breaking changes either. It has, however, a new feature that I personally have missed from time to time; an extra parameter $Schema is added to the Import and Export scripts. And as you may have guessed, it is an PSObject that describes the schema for the particular MA. Having this information allows you to build a little more dynamic into your Powershell scripts used with the PSMA.

Also, a litte logging / tracing bug has been fixed. It is something, you may not have noticed but now it is fixed. It has to do with how the PSMA catches Write-Warning and Write-Error output from your scripts. Remember, you can set your $WarningPreference, $ErrorPreference and other preferences such as Verbose and Debug in your scripts and have the PSMA pick up any output from these statements and output to the Trace log.

Anyways, give the new version of the MA a spin and let me know if you can how it goes.

Thanks,
Soren

Saving FIM / MIM configuration

Just a quick note with a small Powershell script that I made to export configuration for the Synchronization Engine. I use this script on and off at customers to make sure that we can get back to a former state - or move existing configuration from environment to environment when building.

Feel free to use and modify

param

(

$miispath = 'C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin\',

$extensionspath = 'C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Extensions\',

$maexport = ( join-path $miispath 'maexport.exe' ),

$svrexport = ( join-path $miispath 'svrexport.exe' ),

$exportdir = 'export-config'

)

$date = (get-date).tostring('yyyy-MM-dd')

# create base folders with current date

$madir = join-path (join-path (join-path . $exportdir ) $date) 'ma'

write-debug $madir

$null = new-item -path $madir -type directory -force

$svrdir = join-path (join-path (join-path . $exportdir ) $date) 'svrexport'

write-debug $svrdir

$null = new-item -path $svrdir -type directory -force

$extdir = join-path (join-path (join-path . $exportdir ) $date) 'extensions'

write-debug $extdir

$null = new-item -path $extdir -type directory -force

$managementagents = @(get-wmiobject -class "MIIS_ManagementAgent" -namespace "root\MicrosoftIdentityIntegrationServer" -computername ".") 

if($managementagents -eq 0) {throw "There is no management agent configured"}

foreach ($ma in $managementagents)

{

& $maexport $ma.name (join-path $madir "$($ma.name).xml")

}

copy $extensionspath\*.* $extdir

& $svrexport $svrdir

Thanks,
Soren

Securing your Active Directory data before FIM exports

When implementing FIM 2010 at customers, I like to do my own simple backup of the Active Directory objects that FIM is about to touch or change. Of course, you should have your normal Active Directory backup is place as well, but having my copy of  the attribute values allow me to do restore or "roll back" of selected attributes if so needed.

Also, I have a few customers that use these scripts on a scheduled basis to just keep track of changes in Active Directory or even backup before another implementor is allowed to add or change data in their directory.

I have two scripts - a backup script and a restore script.

Backing up

The backup script basically reads the objects that I want to backup from Active Directory and saves these objects in XML files - one file for each object, typically users and groups. The script takes two parameters, the LDAP filter and the backup directory where you want to save the XML files. So to backup all users with accountname starting with A, use the script like this -

.\backup-object.ps1 -filter '&(objectclass=user)(samaccountname=a*))' -backupdir 'c:\adbackup'

Restoring

If at sometime, you would want to restore any attributes on any of the backed up Active Directory objects, you can use the restore script. The restore script takes two parameters as well, a list of attributes that you want restore and a path to the backup directory containing the XML files that you previously backuped up.

The restore script expects you to feed it the usernames of the users to restore through the pipeline. So to restore the 'givenName' and 'sn' attributes on Bill Gates and Steve Ballmer, use the restore script like this -

"billg", "steveb" | .\restore-object.ps1 -attributes 'givenName', 'sn' -backupdir 'c:\adbackup'

If you want the scripts, you can get them here.

PowerShell MA and the FIM Service

I was working on a FIM2010 R2 project where the customer wanted to manage a bunch of DFS groups in the FIM Service / Portal.

However, all the groups (1.600+) would continue to start their life in Active Directory based on some scripts. Therefore we wanted to bring all groups from Active Directory and in to the FIM Service just once and from there on manage all attributes including membership filters from the FIM Service.

Due to precedence, we could not use the FIM MA to create the groups in the FIM Service, so we had to come up with another solution. Again, my PowerShell MA came to the rescue.

Here is how we did it -

1. We created another standard Active Directory MA scoped to the few OU's that contained the groups in question. We set that MA to only import and project a new metaverse type (dfsGroup) and import a few attributes, such as sAMAccountName, displayName, description and such.
2. We then created a PowerShell MA (PSMA) for use with the FIM Service. For this we used my PowerShell MA.
3. We wrote provisioning code to provision all dfsGroup metaverse objects to the FIMService PSMA.
4. We wrote fairly simple scripts to read / write the new dfsGroups to the FIM Service as normal FIM Service Group objects
1. The creation was merely to create a simple security group in the FIM Service. We utilized Craig's Martin's great PowerShell modules for this.

Now we just set the schedules and watched the Synchronization Engine bring in the groups from AD, project them to the metaverse and have them be provisioned to our FIMService PS MA - where the export script elegantly created them in the FIM Service.

On the next import from the standard FIM MA, the new groups would be projected to the metaverse as normal group objects and the groups imported in the normal AD MA could now join - and bum, membership was now maintained using the filters applied when creating the groups using our FIMService PowerShell MA.

Sounds interesting? Get the PowerShell MA here and the scripts here - oh, and don't forget to get the latest cersion of Craig's FIM PowerShell module (although I included the version we used in the download bundle). You may have to change a few lines in the PSMA scripts for logging and such, but beyond that they should be pretty much functional out-of-the-box.

As always, I'm interested to know if you find this useful.

New version of PowerShell Management Agent

I'm pleased to announce that I've released a new version of my PowerShell MA.

This new version now supports two sets of credentials (both optional); the one set of credentials is passed to all the scripts (no change from earlier versions), however, the other set of credentials is used as the security context under which all scripts are run. This present you with some nice options for mixing and matching credentials to build scripts that work under the correct credentials.

Go and check out the new version here and download it here.

Also worth mentioning is that Microsoft released their version of a PowerShell Management Agent this week, so now you have the option to choose which one better suits your needs. You can check out Microsoft's PowerShell MA here.

I use my PowerShell MA a lot for all my engagements and I know a lot of installations are running my PowerShell MA, so I'm dedicated to keeping it alive. As always, I'm very open to suggestions for improving my PowerShell MA - and if you want to make a donation to help me help others, I would appreciate that very much.

I'm looking forward to hearing reactions and feedback from your experience with both versions.

Thank you.

Use FIM and Group Policies to manage Local Administrator permissions

A customer of mine had a requirement to create a domain group for each computer account in their domain. The purpose was very nice. They wanted a domain group to add to the Local Administrators group of each workstation, so that their users could request membership of this group for a period of time, i.e. for installing software that required extra permissions or for managing a laptop that was taken on the road.

It was quite straight forward to import all computer accounts to FIM and use my codeless provisioning framework to create a rule to provision a group to the AD MA for each computer account. Using the codeless framework there was no need to have all computer accounts go to the FIM Service. We provisioned every computer group using the naming convention <computername>-LocalAdmin and afterwards brought the new groups into FIM using another MA - and configured appropriate approval workflows to allow users to request membership of the groups.

The provisioning rule created looked like this (you can read more about the provisioning rules here) -

    <Rule>
      <Name>Provision local admin group to ad</Name>
      <Description></Description>
      <TargetManagementAgentName>ad admin</TargetManagementAgentName>
      <Enabled>true</Enabled>
      <SourceObject>computer</SourceObject>
      <TargetObject>group</TargetObject>
      <Action>provision</Action>
      <RenameDnFlow>
      </RenameDnFlow>
      <Conditions>
        <ConditionBase xsi:type="ConditionAttributeIsPresent">
          <Description>Only if contact has samaccountname</Description>
          <MVAttribute>samaccountname</MVAttribute>
        </ConditionBase>
        <ConditionBase xsi:type="ConditionConnectedTo">
          <ManagementAgentName>cmdb</ManagementAgentName>
        </ConditionBase>
      </Conditions>
      <InitialFlows>
        <AttributeFlowBase xsi:type="AttributeFlowConstant">
          <Constant>CN=#mv:sAMAccountname#-Administrators,OU=LocalAdminGroups,OU=Managed Groups,DC=contoso,DC=com</Constant>
          <Target>[DN]</Target>
        </AttributeFlowBase>
        <AttributeFlowBase xsi:type="AttributeFlowConstant">
          <Constant>#mv:sAMAccountname#-Administrators</Constant>
          <Target>sAMAccountName</Target>
        </AttributeFlowBase>
        <AttributeFlowBase xsi:type="AttributeFlowConstant">
          <Constant>#mv:sAMAccountname#-LocalAdmin</Constant>
          <Target>displayName</Target>
        </AttributeFlowBase>
        <AttributeFlowBase xsi:type="AttributeFlowConstant">
          <Constant>-2147483646</Constant>
          <Target>groupType</Target>
        </AttributeFlowBase>
      </InitialFlows>
    </Rule>

Now, the question remained; how do we effectively get these new computer groups added to the Local Administrator group of each computer, both existing and new computer accounts? Oh, no, it wasn't using PowerShell this time, although I was tempted.

I had a chat with a good colleague of mine from Inceptio, Risto Petersen. Risto is an Active Directory wizard and he had just the recipe; to add a machine specific group to the local Administrators group of every server and/or workstation, you can deploy a Group Policy (GPO) utilizing Computer Configuration Preferences. The steps are -

1. Create a naming standard for your groups including the computername in the group name. In this example I will use <computername>-LocalAdmin, so that for the computer PC1 the group is PC1-LocalAdmin
2. Create the necessary groups, one for each computer object. Use scripting or FIM or some other tool. Remember to keep groups in sync with computer objects; i.e. when a computer is deleted the group should also be deleted.
3. Create a GPO and link it to where your computer objects live in AD
4. Edit this new GPO
5. Go to “Computer Configuration”
6. Go to “Preferences”
7. Go to “Control Panel Settings”
8. Go to “Local Users and Groups”
9. Create a new “Local Group” object for the “Builtin Administrators” group
10. Set the action to “Update”
11. In the Members section add “%COMPUTERNAME%-LocalAdmin” or what your naming standard dictates
12. You might also want to add another general group like “ALL-COMPUTERS-LocalAdmin” to easily delegate rights to all computers

After the next GPO update, your computers will have populated their local Administrators groups with specific computer specific groups. You can then delegate access to individual computers by adding users to these specific computer groups.

A great thank you goes to Risto for this trick - and combining this setup with FIM's self service features, you have a relative simple solution to allow your users access to local administrator permissions.

Use PowerShell to get AD schema information

Sometimes when I engage in FIM 2010 or Active Directory projects, I get the question: "Okay, then which attributes do we actually have in our Active Directory then?". It is a fair question and often knowing the site's actual Active Schema at a given point in time can be useful.

Instead of going to the Active Directory Schema snap-in and manual browsing through the scheam, I've created a small PowerShell script that enables you to dump the schema for a user (or other objectclass) into CSV files (or into the PowerShell pipeline) for further processing.

You may find this information about your Active Directory useful or just fun, so here's there script -

$schema = [directoryservices.activedirectory.activedirectoryschema]::getcurrentschema()
$schema.FindClass("user").mandatoryproperties | select name, commonname, description, syntax | export-csv user-mandatory-attributes.csv -Delimiter ';'
$schema.FindClass("user").optionalproperties | select name, commonname, description, syntax | export-csv user-optional-attributes.csv -Delimiter ';'

There is also a short version of the script if you don't want any fancy selecting and exporting, but just want the attribute information in your pipeline -

$objuserclass=[adsi]”LDAP://schema/user”
$objuserclass.mandatoryproperties
$objuserclass.optionalproperties

Feel free to modify it to your specific needs and of course make sure that you run it as a user that has permission to dive into the Active Directory schema.

Enjoy.

PowerShell 5.0 Management Agent released

I'm very pleased to announce that version 5.0 of my PowerShell Management Agent is released and available for download.

This new version includes these key improvements -

• Additional control values on your import and export return objects
• Ability to returned datasource constructed anchors, i.e. from Office 365 and SQL server
• Option to use paged imports, which gives you even more control in your scripts and better support for stopping runs.
• Bug fixes and increased robustness.

I'm not going to spend a whole lot of time on these new features but instead than refer you to the updated online manual which also has links to downloads. Also, this version was the one used at my presentation and live demo on the FIM Team User Group meeting. You can view it here on YouTube.

I'd like to hear from you - good or bad news - and I'm of course always open to feature requests. So please do let me know what you think about this MA and I also very much appreciate a "Like" on my blogs page on Facebook.

Happy PowerShell'in...

My talk on the PowerShell Management Agent

Yesterday, I did a short talk and demonstration of my PowerShell Management Agent for FIM 2010 R2. From the comments made during the presentation and in the question round, there seemed to be a lot of interest for the MA.

As I mentioned during the demonstration, I have a new version coming out very soon which will have all the new features that was discussed on the meeting. Should you be interested in a pre-release version, then let me know and I'll get you a download link for the pre-release version (subject to change of course).

If you missed the presentation on the FIM Team user group meeting yesterday, you can view here on YouTube.

Also, there was some interest for the PowerShell scripts used for the demo; if you would like to study these more closely, you can download them here. There was a few questions on the provisioning used for the demo setup, and for those interested in this, take a look at the Codeless Provisioning Framework that I'm maintaining on Codeplex and which was used for the demo setup.

Again, thanks for all the nice words and comments about the presentation and the PowerShell Management Agent. And also, thanks to the FIM Team for this speaking opportunity.

FIM 2010 R2 Service Pack 1 / BHOLD released

The news is already out there, but I thought I'd just write a quick note on it as well.

On MSDN, you can download Service Pack 1 for FIM 2010 R2 and BHOLD. Note that there are two versions available - one for new installs and one for upgrades to existing installations.

I've yet to play around with this new Service Pack - and with support for newer versions of Windows Server 2012 and SQL Server 2012, it looks as if I've got my work cut out testing and I also need to upgrade my PowerShell kit for that automates FIM2010 R2 / SharePoint 2010 installation scripts to support the new version.

As far as I know there is no official KB article or document telling us exactly what the news in this release is. So I guess everyone is looking for to that and I will definitely want to read that before I upgrade any production environments.

As I dive into this new service pack, I'll be sure to share my findings - so stay tuned.

UPDATE. Jorge has a little more information to share on this here (http://jorgequestforknowledge.wordpress.com/category/forefront-identity-manager-fim-sync/)

Dump your Active Directory schema

Now and then I need to dump the current Active Directory schema or just do a little research in the schema.

Being a PowerShell junky, I won't go to ADSIEDIT even though that might seem easier at first. I'd much rather have the entire list of attributes as objects for filtering and sorting. So, PowerShell to the rescue.

(New-Object adsisearcher ([adsi] "LDAP://CN=Schema,CN=Configuration,DC=fabrikam,DC=com", "(objectclass=attributeSchema)")).FindAll()

Give it a go the next time you near a domain controller and have just enough permissions.

PowerShell Management Agent 4 released

I'm very happy to announce that version 4 of the Granfeldt PowerShell Management Agent is available for download.

This new version has support for deltas and can scale very nicely.

This Management Agent has proved to be a regular switch army nice for getting FIM to talk to systems that have no Management Agent. There have been reports from around the globe of people using this Management Agent for managing anything from Office 365 users, Lync users, Exchange mailboxes to DHCP scopes.

I'm very happy to see the 500+ downloads of the previous version here in 2012 and trust that this new version will also reach that number.

Support?
The popularity of this Management Agent also mean that I do get a lot of support questions and kind requests for help in constructing the PowerShell scripts for use with this MA. I cannot accommodate everyone, so please do not be surprised if I don't answer your mail with support questions.

As a lot of people around the world are using this MA, I recommend that you direct your questions to the general FIM 2010 forum where a lot of skilled FIM guys and girls are ready to help. I'm also monitoring that forum and will try to answer questions from time to time.


Get the MA and help a good cause/charity in 2012
I'm currently trying to gather a small amount of donations for a good cause/charity here in 2012. So if you're using the PowerShell MA and download the new version, then please do consider making an appropriate donation. By the end of the year, I'll donate the amount collected to a childrens hospital here in my hometown, Odense, Denmark - with appropriate credit to donators.

Finally, I want to thank Kent Nordström and Jason Taylor for their assistance in rooting out any obvious bugs for this release.

So now, go read all about it and get it here. And please help spread the word on Twitter and other appropriate medias.

Only the bare minimum, please..!

Once again, I find myself in a discussion of setting up the FIM Active Directory service accounts to only have the minimum permissions needed for the job.

I won this time (again) - and I'm now finding my self creating PowerShell scripts to make sure that the service account used for the FIM Active Directory MA only has exactly the permissions needed for it to be able do it's work.

I'm using DSACLS and PowerShell for the script/job. If you're not to familiar with either above, you can find very good inspiration in this blog by Paul Williams.

And remember "To script or NOT to script, that is a stupid question"; now go and restrict your service accounts in FIM..!

ECMA 2 PowerShell Management Agent 1.0 released

I'm pleased to announce that my PowerShell Management Agent (MA) has been released. This version is a completely rewritten Management Agent and is now built on the ECMA 2.0 Framework that is included in the FIM 2010 Rollup 2 and of course in FIM 2010 R2.

The PowerShell Management Agent is very flexible allowing you to define your own schema (using a PowerShell script) and run scripts for Full Imports and Exports. The download includes complete documentation, so I won't write more information in this blog entry.

You can get the bits here.

Please note that I'm not able to offer free support for this, however, you can sign up for official support for this Management Agent if you do so wish. Please contact me for more details on a support agreement.

PowerShell Management Agent 2.0

I'm pleased to annouce that a version 2.0 of my (apparently popular) PowerShell Management Agent is released.

The old version only supported exports, but this new version also supports imports (only Full Imports) giving you the option to do a lot of data source interaction in pure PowerShell. You can read much more about the inner workings of the Management Agent in the documentation included in the downloadable.

You can find the binaries and documentation here.

If you have feature requests or find bugs, please let me know.

The released version is as-is, however, you can contact me for details on support options if this is required for your setup.

Refreshing the FIM portal

Carol Wapshere did a nice post on refreshing the FIM portal when you make changes to RCDC and such. I've taken this to heart and put together a small Powershell script to do the job.

You can use the script like this -

"AppPool name" | .\Recycle-IisAppPool.ps1

i.e. "Sharepoint - 80" | .\Recycle-IisAppPool.ps1

You could even send several AppPool names through the pipeline, i.e.

"SomeAppPool", "Another AppPool", "Sharepoint - 80" | .\Recycle-IisAppPool.ps1

Ooh, and the script; here it is (remember to save it with a .ps1 extension)

process
{
 $_ | % { Invoke-WMIMethod -Name Recycle -Namespace "root\MicrosoftIISv2" -Path "IIsApplicationPool.Name='W3SVC/AppPools/$_'" }
}

Powershell Management Agent for FIM 2010 released to public

UPDATED: September 11, 2012 - Old version has been replaced by the ECMA2 version. That can be found here http://blog.goverco.com/p/powershell-management-agent.html
UPDATED: See http://blog.goverco.com/2012/01/powershell-management-agent-updated.html

I've decided to release my Powershell Management Agent to the general public. You'll find all the binaries and documentation (see update).

For more information on the project, see my previous blog.

This project has been created in my sparetime, and I do not except to get paided for this kind of work; however if you find this Management Agent valuable and you use it commercially, please donate appropriate amount (suggested amount if used commercially is $250) to encourage further development and bugfixes.

Happy scripting and please let me know good and bad findings with this Management Agent.

The Granfeldt PowerShell Management Agent

UPDATE: September 11, 2012 - Find new version here http://blog.goverco.com/p/powershell-management-agent.html

I'm pleased to announce that my PowerShell Management Agent has been released and is available upon request.

The Granfeldt PowerShell Management Agent is a diverse Management Agent (MA) that can be used for many different purposes. Basically, any task that can be done in PowerShell can be triggered through this MA, making it very flexible and a regular hybrid MA.

The MA is built using the Extensible Management Agent (ExMA) framework provided as part of the Forefront Identity Manager 2010 (FIM 2010) product. Upon request, a version can be made available Microsoft Identity Lifecycle Manager 2007 (ILM 2007).

The Management runs as an export-only Management Agent that allows for a PowerShell script to be run for each object that is provisioned to the Connector Space (CS) of the Management Agent. The name of the PowerShell script to be run must follow each object when it is provisioned in the attribute named ScriptFullPath. The script will run on add, modify and delete of objects in the CS.

By using traditional provisioning code or Synchronization Rules in FIM, you can provision new instances of objects for which to run scripts.

The following shows an example of a CS object being passed to the script –

Id: 464286ED-5F81-4A82-8172-EA1549AC0901
ScriptFullPath: C:\Scripts\Manage-HomeDirs.ps1
uid: User1
displayName: Test User1
homeFolderRoot: \\fs001\HomeFolders

When this object is exported to the script, the actual PowerShell script command line will be –

C:\Scripts\Manage-HomeDirs.ps1 –DN 464286ED-5F81-4A82-8172-EA1549AC0901 –Id 464286ED-5F81-4A82-8172-EA1549AC0901 –ObjectClass person –ModificationType Add –ChangedAttributes uid, displayName, homeFolderRoot –uid User1 –displayName “Test User1” –homeFolderRoot \\fs001\HomeFolder

If you'd like to receive a version of the code for testing purposes, please drop me an mail on soren@granfeldt.dk; please let me know if you are using ILM 2007 or FIM 2010, so that I can get the correct version to you.

The MA is also available for purchase; please contact me for price and details.