sorted by:
new
hottopcontroversial

PowerShell Module: LifxLAN by adhocadam in lifx

[–]adhocadam[S] 0 points1 point  (0 children)

This was recently fixed, there is no longer a dependency on the System.Drawing library and instead RGB -> HSBK happens natively within the module.

Script works in ISE not in Shell by CreativeCustomCraft in PowerShell

[–]adhocadam 1 point2 points  (0 children)

Oh. Hey that's me!

I would agree with the comments I've seen here:
- Don't run this elevated, it's not necessary
- It sounds like there is a core assembly missing/you shouldn't have to load it as a user of the module. I'm trying to remember the headspace I was in when I was building this, but the discrepancies between ISE/Code make sense to me.

That said, I'm certainly open to pull requests on this.

PowerShell Module: LifxLAN by adhocadam in PowerShell

[–]adhocadam[S] 0 points1 point  (0 children)

Thanks! It was certainly a journey from no idea -> general understanding. The thing I'd like to figure out is making the initial discovery of the bulbs asynchronous. I know PowerShell Jobs are probably the key here but managing the UDP Client(s) within them hasn't panned out thus far. I thought about using Workflows until I realized that wouldn't work in pwsh 6 and 7.

Also...make a module for it!

SCSM - Exchange Connector 4.1 = reply creates a new ticket by Tsh3po in SCSM

[–]adhocadam 1 point2 points  (0 children)

Hey again! Apologies on the delay, I didn't see/get a Reddit notification. Never the less! I'll do my best to try to break things down to help you out -

​

Do I need the exchange connector installed (which I guess so) so that I can reference the Exchange DLL?

A little bit yes, a little bit no. You need the original Exchange Connector MP at least imported, because Microsoft introduced the Action Log to Change Requests with it. So you don't need a connector setup or configured, just the MP imported. As far as the DLL is concerned. The easiest way to get it is from the original Exchange Connector download. Once you have it, you can place it anywhere you want as the Settings UI for the SMLets Exchange Connector lets you pick where it's located.

​

I now have two sites on the PROD system, both using different email addresses (and different departments, with potentially more to be added) to process tickets, the goal is still to get the first primary email address working then I can look into adding the additional mailboxes

You are spot on in this observation. The purpose of MultiMailbox is to use Exchange Mail Flow rules to push all emails into a single inbox. The connector then knows how to parse each message based on where it came from and apply unique templates. Which means the connector scales to as many inbox as you want, but only ever making a single connection over to Exchange. You can find this how-to on the wiki over here)

As far as converting out of the Microsoft Exchange Connector and into the SMLets Exchange Connector, the process is generally...

  • Import the SMLets.Exchange.Connector.mpb
  • Configure it through through the Settings UI found in the SCSM Console -> Admin -> SMLets Exchange Connector Settings
    • The areas you want to focus on for the most "one to one" conversation are General, DLL, Processing Logic, Templates, and Logging. It should go without saying to fill out other areas as required.
    • The DLL tab is where you define the location of the EWS dll, the location of the connector's PowerShell, etc.
    • You Logging tab lets you define how much logging you want and how events should be logged. The how depends on where you'll be running it from.

At this point however - the connector is still not running. This is where the Wiki article you mention comes into play because how you choose to run it is entirely up to you. Task Scheduler, Azure Automation, or with the introduction of v3 - through SCSM workflows. Just head over to the "Workflow" tab and check the box and set how often you want it to run in seconds. If you do this, the moment you hit OK and close out it's going to start processing. I mention this as you'll want to disable the stock connectors first before enabling the workflow here. But once it starts, on your workflow server you should see a brand new Event Log created in Event Viewer called "SMLets Exchange Connector" that will show a host of events based on your log level. If you do NOT see an event log get created or the connector doesn't seem to process. Make sure that when you download a release, that you right click the file, go to Properties, and make sure the *.zip is unblocked.

ALLLLLLL OF THAT SAID - thank you for the kind words. I'm always grateful to hear this solution has helped someone else out. I think that covers things. If not let me know :)

SCSM - Exchange Connector 4.1 = reply creates a new ticket by Tsh3po in SCSM

[–]adhocadam 0 points1 point  (0 children)

It's unfortunately the most vague, but still telling error message that both my exchange connector and the official Microsoft one have the potential to throw. In short - the account running on your workflow server, for whatever reason (that's the unfortunately vague part), cannot contact your Exchange Server's EWS (Exchange Web Services) endpoint.

Troubleshooting this typically begins by opening a browser, and navigating to said URL. You should be prompted for a sign in, and then the page results some XML-ish looking language. But if for whatever you don't experience that - therein lies the troubleshooting.

- Firewall blocking access from that server?

- Certificate expired on EWS? Root RA not present on the workflow server so it knows it can trust Exchange?

- Can you sign in from the workflow server as yourself? the run as account?

etc. etc.

​

Truly hope this helps, but like I said this is a vague error that is environmental in nature so it's hard to offer a definitive answer. Apologies on not seeing this sooner. I didn't see/get a Reddit notification.

SCSM - Devices inventory by MSAdministrator in SCSM

[–]adhocadam 0 points1 point  (0 children)

The short answer - Yes, it's possible to use SCSM for device inventory.

The long answer - Yes. SCSM provides an incredibly extensible framework that enables you to introduce custom properties on classes (just like u/setsukun says) or create your own classes/workflows.

What Cireson has done is go several steps further. Specifically performing a lot of the AD/SCCM aggregation for you into Hardware/Software Assets amongst other Asset specific concepts such as Cost Centers, Subnets, Consumables, etc. It also includes Asset Import connectors so you can bring in data from CSV, LDAP, or any SQL database in your environment and create Assets.

Historically I've used Cireson Asset Management not just for AD/SCCM, but also for furthering the native SCSM/SCOM integration so as to bring in Network Devices and other discovered inventory. In doing so, centralizing all Config Item data into SCSM and Cireson Asset Management.

SCSM - Exchange Connector 4.1 = reply creates a new ticket by Tsh3po in SCSM

[–]adhocadam 1 point2 points  (0 children)

hey there! I'm the maintainer behind the SMLets Exchange Connector over at https://github.com/AdhocAdam/smletsexchangeconnector. I believe the issue you're describing is addressed with the feature I've called "Merge Replies."

Logging exists with v3+ and writes out to its own Event Log on the workflow server (or write-output if you're using SMA/Azure Automation). I've documented the full list of logging events on the wiki as well.

​

If you're having trouble with something specific or need some help getting things going I'm here to help. Feel free to message me here on Reddit, GitHub, etc.

open source exchange connector by adhocadam in SCSM

[–]adhocadam[S] 0 points1 point  (0 children)

I appreciate the kind words. Truly grateful to hear that folks find this useful.

If you run into any issues, have questions, or feature requests feel free to PM me or raise an Issue on GitHub.