Hi Guys,
hope you all had a good start into a new year. At my company we recently started with RDM, and in general it's running just great. However, when they noticed there were supposedly Powershell Cmdlets for this product, I had some barbarians at the gates (colleagues at my desk), demanding (requesting) that I integrated those into our internal use only Powershell Console product (me being the local Powershell Developer).
Alright, so I got started, found them easily enough and ... raised my hands in frustration. PSSnapins of all things, and 32 bits only (Our Enhanced Powershell Console is running 64bit only). If memory serves right - it often does where Powershell is concerned - those were deprecated when Powershell v2 was released some years in the past.
So here's the simple request: Please release a module version that's x64 compatible. (Note: The "simple" referrs to the linguistic difficulty of phrasing the request, not the difficulty in implementing it![wink]()
)
Alright, with that out of the system, here's some background why it would be a real enhancement for us:
We're an IT Service Provider (2nd Level Support & IT Project Management/Implementation mostly), so our techs often work on customer systems, either remotely (Guess what's coming in handy here?) or while onsite. Your product requires local installation for the Powershell Cmdlets to work, which in many cases is impracticable for us. From what I can see, the Cmdlets directly tie into the main libraries installed with your client application, making them highly importable. I assume this also is the major reason why the x64 Port is proving so difficult, since it's not simply a case of recompiling a WCF Client Library.
The only way I see this being made to work, is for the (to be created) Module to communicate directly with the Server (Being a Powershell / C# kind of person, I'd favor using WCF - Windows Communication Foundation - for the task).
Now many of our Technicians use our console for lots of routine tasks (quite a few open it before they launch their Mail Client and close it as the last application before shutdown). Many of our more complex workflows require console work. This means, that tool is always at hand, and being able to seamlessly integrate RDM access into it would allow major leaps in workflow automation. Examples:
- The technicians have instant access to session information
- The technician can easily add new data entries as he works setting up systems
- Our own Powershell functions can directly use the up-to-date Information from RDM
- Allows tracking use of RDM-Stored data
Now wouldn't that be fun?
Cheers,
Bosparan
Ps.: Don't know if the Terms of Use allow for it, so I thought I'd ask: Is it ok for me to decompile your libraries and take a peek at your Cmdlets? I kind of like to provide feedback by concrete examples on how I'd implement it, rather than a "Hey, wouldn't it be great?". If the ToU disallow it, would you mind granting an excemption?
hope you all had a good start into a new year. At my company we recently started with RDM, and in general it's running just great. However, when they noticed there were supposedly Powershell Cmdlets for this product, I had some barbarians at the gates (colleagues at my desk), demanding (requesting) that I integrated those into our internal use only Powershell Console product (me being the local Powershell Developer).
Alright, so I got started, found them easily enough and ... raised my hands in frustration. PSSnapins of all things, and 32 bits only (Our Enhanced Powershell Console is running 64bit only). If memory serves right - it often does where Powershell is concerned - those were deprecated when Powershell v2 was released some years in the past.
So here's the simple request: Please release a module version that's x64 compatible. (Note: The "simple" referrs to the linguistic difficulty of phrasing the request, not the difficulty in implementing it
)Alright, with that out of the system, here's some background why it would be a real enhancement for us:
We're an IT Service Provider (2nd Level Support & IT Project Management/Implementation mostly), so our techs often work on customer systems, either remotely (Guess what's coming in handy here?) or while onsite. Your product requires local installation for the Powershell Cmdlets to work, which in many cases is impracticable for us. From what I can see, the Cmdlets directly tie into the main libraries installed with your client application, making them highly importable. I assume this also is the major reason why the x64 Port is proving so difficult, since it's not simply a case of recompiling a WCF Client Library.
The only way I see this being made to work, is for the (to be created) Module to communicate directly with the Server (Being a Powershell / C# kind of person, I'd favor using WCF - Windows Communication Foundation - for the task).
Now many of our Technicians use our console for lots of routine tasks (quite a few open it before they launch their Mail Client and close it as the last application before shutdown). Many of our more complex workflows require console work. This means, that tool is always at hand, and being able to seamlessly integrate RDM access into it would allow major leaps in workflow automation. Examples:
- The technicians have instant access to session information
- The technician can easily add new data entries as he works setting up systems
- Our own Powershell functions can directly use the up-to-date Information from RDM
- Allows tracking use of RDM-Stored data
Now wouldn't that be fun?
Cheers,
Bosparan
Ps.: Don't know if the Terms of Use allow for it, so I thought I'd ask: Is it ok for me to decompile your libraries and take a peek at your Cmdlets? I kind of like to provide feedback by concrete examples on how I'd implement it, rather than a "Hey, wouldn't it be great?". If the ToU disallow it, would you mind granting an excemption?