Christmas time is upon us, and I’ve decided that my PSTeams module needs some love. I wrote it in late 2018 and updated it a few times at the beginning of 2019. This release hopefully is worth of having 1.0 version number. I don’t do that often and usually go for build numbers changes only, but Microsoft Teams message cards have their limits on functionality. Therefore, there are not many things that can be added unless Microsoft opens up and gives us all the cool features of Adaptive Cards. PSTeams module uses Webconnector to send messages to Teams. That method only supports Message Cards, which even Microsoft calls Legacy. But legacy doesn’t mean fully functional with some cool features of their own. If you’re new to PSTeams you may want to read those 2 posts below to get information how to set it up.
powershell
In the last few days, I’ve got two reports that my PowerShell module for Office 365 Health suddenly started giving errors. This was a bit weird because it worked perfectly fine on my end. But while I could understand one person having an issue of their own, with their network or firewalls, if the second person comes along with the same report, that means something else is going on.
Some time ago I’ve wrote PowerShell way to get all information about Office 365 Service Health, and if you were thinking that I would try the same concept for Azure Services you were right. However, I failed. This is because Office 365 Health can be gathered using Microsoft Graph API, and Azure Health information, as far as I know, is not available in the form I wanted it. Azure Status is available as part of Azure Status website. Contrary to Office 365 health you don’t have to login to your Office 365 tenant to read it.
Today I had a need to connect to Microsoft Graph and do some tasks on Office 365. Since I have already done similar stuff for my PSwinDocumentation.O365HealthService PowerShell module that I’ve described in PowerShell to get all information about Office 365 Service Health, I thought this will be easy run as I’ll just reuse the code I’ve done for that module. As always for Graph related tasks you need to register your application and assign correct permissions. I’ve used my own article for that with changes to which API I want to access. Now that I’ve done all that I’ve extracted my Connect-O365Graph function from my module and started connecting.
I have to admit – executing the same command three times and expecting different results is dumb, but I still do it anyway. Fortunately, after trying three times I usually resort to other methods and try to solve the problem I have. Today while trying to trust PowerShellGallery I was greeted with an error.
We need to deal with a group names through SID’s rather than names because each group name is different in different languages. The second problem is to distinguish whether a user is a local or domain user. Finally, I need to connect to Active Directory to verify if the user I am about to remove has ExtensionAttribute10 (or any other field in AD) filled in or not.
If you don’t know this yet, I use PSWriteHTML a lot. That means I get to test it under a lot of different conditions. I use it in reports, emails for small, medium, and large companies. Today’s blog post summarizes the work I did in the last few weeks over different areas of PSWriteHTML.
Recently I got a simple task to implement LAPS for the newly created local user instead of using the built-in local administrator account. It seemed easy at first. Go to Group Policies, create a new user, add it to an administrators group, and then follow standard steps to implement LAPS. That is until you find out it’s actually not possible anymore due to password encryption key being available in the wild, which made Microsoft block that Group Policy Preference. While that road is blocked, I still need to get my user-created somehow. Let’s do it with PowerShell. It’s quite simple – use New-LocalUser a few parameters, some random password that I don’t need to save as LAPS will overwrite it. Except it’s not available on PowerShell 2.0, which is the default for Windows 7 that I have to support. Things get even more complicated if you consider that Administrators group is called differently in different countries. While I stopped supporting anything below PowerShell 5.1, I can’t say if it’s the project requirement.
One of the new features I’ve worked on was connecting Diagrams with Tables. Someone suggested, and I thought it would be cool to be able to click on the Diagram node and find more details about it in a table next to it. But then I thought it would be even cooler if you could have multiple tables linked to one Diagram. For example, below, I’ve created two tables with Users and Computers and populated Diagram with that data.
A few months ago, when I was working on PSWriteWord and PSWriteHTML, I thought to myself that in 2020 if I’ll get time, I’ll try to create PSWriteVisio. While I wasn’t sure I would be able to make it past some concept, it was in my plans for 2020. It’s still 2019 though, and while working on Testimo for Active Directory Healthchecks, I thought it would be nice to have a visual representation of network, forest schema or replication. I couldn’t get this idea out of my head. I thought on using PSGraph from Kevin Marquette to generate image and import that to PSWriteHTML but it was a bit tricky and PSGraph requires external software to work – and has some additional steps for Windows, Mac or Linux.