I am trying my first V4 script…
I read the documentation and still have questions. Not sure if I am alone but I will give a try.
Here, I adapt the
\PSAppDeployToolkit_Template_v4\Config\config.psd1 for my need.
Then I launch: Import-Module "$scriptDirectory\_Include\PSAppDeployToolkit_Template_v4\PSAppDeployToolkit\PSAppDeployToolkit.psd1" -Scope Local
$adtSession = Open-ADTSession -SessionState $ExecutionContext.SessionState @adtSession@PSBoundParameters -PassThru
What should I do for ADT taking my config.psd1? As I read it should read the default one first then the modified one. Sound its not the case.
If I need editing PSAppDeployToolkit.psd1 or psm1 then where should I copy them to be able editing them and keep it working (debugging need or testing). Actually we are using remotesigned but I worry even with remotesigned the psd1 will not be working?!
How may I force a logname?
About the values returned from open-adtsession, are they wrote in the logs like it was in V3? If not then what should be done?
I understand the documentation is still in progress.
I am assuming that you are talking about modifying the Invoke-AppDeployToolkit.ps1 before deploying it. Is that correct?
What I did was to place another script in the root of the source folder (next to the Invoke-AppDeployToolkit.ps1 script). I just named it Connect-AppDeployToolkit.ps1.
The only downside with it that I’ve found so far is that I need to declare the AppVendor, AppName and AppVersion variables in both the Connect-AppDeployToolkit.ps1 and Invoke-AppDeployToolkit.ps1 scripts if I want to refer to those variables while writing/testing the Invoke-AppDeployToolkit.ps1 script.
The upside is that it is loading my changes from the Config.psd1 file and also loads the .\PSAppDeployToolkit.Extensions\PSAppDeployToolkit.Extensions.psm1. We have a LOT of extensions that we use.
Hopefully it’s formatted correctly and hopefully helps you out. It’s still a work in progress. There are a few other things I’d like to add in the future.
You have some interesting stuff and I will give it a try. Am I alone finding v4 is harder to put in place comparing with v3? I tried debugging write-adtlogentry and found the code harder to understand
Did you found a way to change the default logname?
In V3, we were just writing : Write-log “this is a test” and the I was getting the correct logname and path but seems now I have to set the commandline parameters to get it correctly. Do you have a trick?
I am finding there be quite a learning curve with v4, although I did with v3 as well since I was VERY new to PowerShell in general then.
Logging seems to work fine when running the Invoke-AppDeployToolkit.ps1 as long as I have the ADT Session info filled out, like AppVendor, AppName, etc. Otherwise it is logging to “C:\Windows\Logs\Software\PSAppDeployToolkit_4.0.4_EN_01_PSAppDeployToolkit_Install.log”.
I don’t know where lines like this have come from, as $scriptDirectory isn’t defined or used anywhere in our Invoke-AppDeployToolkit.ps1 template we provide.
I strongly urge you to download the provided v4 template from here and simply run it as-is to get a feel for it, then start customising things to your requirements.
Are you wanting to force a log file name for the entire deployment? You can add -LogFileName myLogFile.log to the end of the Open-ADTSession call and that’s what the toolkit will use.
I don’t quite understand the point of this if I’m being honest. Let’s try to keep it simple for Francois while he’s getting started as it seems he’s gone off the rails already.
The bulk of the log writing code is now in our C# library as the entire session controller is C#-based out of necessity due to PowerShell limitations, immutability, and performance.
What I do is trying to include the appdeploy toolkit inside our own code. So scriptdirectory is the current folder.
In V3, I was able using just write-log 'test". So it was easier and faster to code. We are extending debugging our code with write-log.
If you wrote the buld in c# then it get harder to debug. That’s bad for me as I learned a lot my powershell from your v3 code and contributed debugging. Not everyone know c#. I am undertanding why you did it but there is a downside,
In your open-adtsession, there should be a line confirming the modify config.psd1 template is load. I saw nothing excdpt the default one.
The problem is you’re trying to run before you’ve learnt to walk. You should be taking a step back and running the toolkit via our template first to get a feel for things before trying to integrate it into your own code. We can help with general issues with our template, but you’re on your own when it comes to your own code because we don’t know it and we haven’t seen it.
You can still call Write-ADTLogEntry -Message Test, but the module providing the function needs to be imported correctly and Open-ADTSession needs to have been called also. The combination of importing the module and opening a new session is effectively the equivalent of dot-sourcing AppDeployToolkitMain.ps1 from the old days.
We discussed the downsides of the C#-based DeploymentSession class. In fact, it was a PowerShell class until November. It just had too many issues, you cannot reliably use PoweShell classes for anything more than data storage. Arguably the debugging experience has improved since you can debug with Visual Studio, but I know and appreciate that’s beyond a lot of people.
You might be better off downloading the v3 compatibility template we provide? It provides an AppDeployToolkitMain.ps1 file you can dot-source like previously. This compatibility layer won’t be around forever, but it’s a good stopgap until you get fully up to speed.
I know you’ve said a lot of different and things are harder to use, etc, and they probably are, but every change we made has been to ensure the longevity of the project and to see it move in the right direction. The v3 code worked, but it was at the end of its lifetime as it’s simply not how you develop such a project in 2024. Once you’ve got a handle on things, I’m sure you’ll see the improvements and come to love our v4 solution.
I don’t want to hijack your thread, but I think we may be having some of the same issues. If that is not the case, please let me know and I will stop responding here and maybe create a new topic.
What I used to do in v3 was to open PowerShell ISE as Admin and then run AppDeployToolkitMain.ps1. This would:
Load all of the PSADT functions
Load all of our custom functions from the AppDeployToolkitExtensions.ps1
Load default values for the $appVendor, $appName and $appVersion
This would allow me to use Intellisense with all of the items above. How do we accomplish that with v4 since the Invoke-AppDeployToolkit.ps1 closes the ADT session? This is what I was trying to accomplish with my Connect-AppDeployToolkit.ps1.
With this in mind, your solution makes sense for that purpose. I believe Francois is trying to do something with a production solution more so than bootstrapping the toolkit for the ISE. His underlying issue is likely resolved by ensuring -ScriptDirectory is supplied to Open-ADTSession so it knows where to look for the config.
For your use case, you could install the module from the PSGallery, then it’d simply be available in the ISE. If you really needed a session to be open also, that’d just be a one-liner such as Open-ADTSession -SessionState $ExecutionContext.SessionState. You could also download the v3 compatibility layer and dot-source AppDeployToolkitMain.ps1 as it will do exactly that also, however as said it will disappear at some point in time.
Any reason for still using the ISE? I try to steer people towards more modern tooling such a VSCode, etc.
Are you wanting to force a log file name for the entire deployment? You can add -LogFileName myLogFile.log to the end of the Open-ADTSession call and that’s what the toolkit will use.
I was not aware this way to set a default log file. I will give it a try. May be the documentation should reflect the way to pass from v3 to v4, integration in custom scripting too.
Not everyone are using ADT in a pure way.
With SCCM, there are comliance script where I am writing only with pure powershell. So we are just copying powershell function to get write-log and other functions. So using v4 template is not an alternative and c# is an imortant downside.
VSCode is not install on all computers but ISE is. When packaging, I am working on many computers and I don’t have to install and configure VSCode each time. I am packaging since 2008 and using VSCode since 2014.
Don’t forget you are dealing with old timer too
When working on my own computer and programming VSCODE is correct. But if I go on a user computer and trying to debug a package then ISE is the way. If I need installing multiple computers and packaging then installing VSCode, IMHO, is a lost of time.
Our documentation is improving, but we can only document custom usages of the toolkit to a certain point. If you’re at the point where you’re creating custom scripts that integrate our toolkit into your own solutions, you’ll also need to put the effort in to understand how v4 works so you can achieve the outcome you desire.
With the v4 module, you should be able to import it from a network location and have all the functions you need available to you without using to copy/paste code around. We need to ensure that the needs of the project are met first and foremost, and the logging code is in C# because it belongs with the DeploymentSession object and is also dramatically faster. After migrating the ADTSession PowerShell class to the DeploymentSession C# class during development, we saw an 8x performance increase in overall performance of the object, including logging etc. Additionally C# provides the necessary capabilities to power compatibility mode as well
There’s nothing wrong with the ISE, it’s just old and there’s better tooling out there. Doing debugging on a client machine is a perfect use case for it, but on your daily device using VSCode would be recommended, and it seems like it’s what you’re doing anyway.
Our documentation is improving, but we can only document custom usages of the toolkit to a certain point. If you’re at the point where you’re creating custom scripts that integrate our toolkit into your own solutions, you’ll also need to put the effort in to understand how v4 works so you can achieve the outcome you desire.
I agree I have to understand but to understand, you have to explain.
With the v4 module, you should be able to import it from a network location and have all the functions you need available to you without using to copy/paste code around. We need to ensure that the needs of the project are met first and foremost, and the logging code is in C# because it belongs with the DeploymentSession object and is also dramatically faster. After migrating the ADTSession PowerShell class to the DeploymentSession C# class during development, we saw an 8x performance increase in overall performance of the object, including logging etc. Additionally C# provides the necessary capabilities to power compatibility mode as well
Network locations are not always available. Many users are connecting rarely with VPN and never going to office. SCCM Compliance is working even with no network locations by using a CMG. Even with Intune, if there are no network location then you are dead. So Powershell is still mandatory.
I agree completely, my comment was based on the suggestion we should have documentation on custom integrations, but there’s only so much information we can provide on that.
The other option is to install the module onto workstations. This will mean it’s always there and then can also be used with detection scripts and proactive remediations.
The other option is to install the module onto workstations. This will mean it’s always there and then can also be used with detection scripts and proactive remediations.
Yes but that would mean maintining another software on all workstation. ADT goal is to reduce the headache of deploying software not adding one Another software sources with all security risk, update, etc…
I’m just spitting out suggestions here. Arguably installing the module means less code in your own script, which makes security updates easier.
The problem is you’re saying that v4 is harder to use because you can’t cannibalise it and take functions for your own needs, etc, which isn’t something we can really do anything about. Our goals are to make a better product for installing applications using the toolkit as it is, and I thoroughly believe we’ve delivered a fine product that’s only going to get better with each minor release.
Initially I don’t think you realised the bulk of the logging code was in C# until I mentioned it though. Regardless of that, are you getting along any further with v4 on your side? Is there any more info or insight I can give you to help get you going?
