The simple answer is yes, and yes, but the exactly how you get there is going to be a matter of experience. Unfortunately, this is one of the more sophisticated types of things to want to pull out of landesk. There are many sections in the inventory that cover patches, and you can write ldms queries to work with this information. You can create output columns of info that can include the server's name, as well as the patch name, and its status. You will likely need to keep item 1 and 2 separate. It would be very complex to try and combine those. Additionally, with as many patches that exist, expect a VERY long report depending on the device count that you're working with. Multiply the total number of patches that exist in your system times the number of devices and that could be the number of rows in your report! Probably will be less, but you can see where this could get ugly fast. Sometimes MGMT doesn't really know what they are asking for, but we all know how that turns out. At any rate, there are items to tell you success of a patch installation, its status, many other things. Just look through the inventory of a machine at the items that mention patch or security, and you'll be in the right places.
For someone new to it all, i'd suggest you start with the builtin reports, and also work with the builtin features that exist in the console.
For example, under the patch section, you can look at the the lists of "scanned" patches and get an overall view of what is "Detected", vs. "Scanned", vs. Not scanned, and so forth.. this is a good starting point for understanding what is happening after a patch deployment. You'll be able to right-click any patch and choose "Affected devices" and it will present a list of the devices that are needing to be patched still, so that's useful for figuring out which machines still need to patch. Keep in mind that pending reboots will keep a machine as showing affected, until the machine reboots. Then the device should perform an update scan and its status will change pretty much real time in the panel, BUT there's some tables that won't update right away.
One thing that is very critical about reporting on patches is making sure that you have a scheduled task that runs periodically to perform the GatherHistory process. Without this, it wouldn't matter much to try to report on patch results. This process keeps everything reconciled in the various tables in the DB. There's a lot of data to work with, so you have to know which area to look in and WHEN to look at it. You always want to look at the Security and Patch information AFTER a Gatherhistory has been done, which needs to happen after a patch deployment occurs. So if you know you're going to push some patches at X, make sure that Gatherhistory has been run after X, and that you perform your reporting after that. Otherwise you won't get the real results of the status of patches.
Hope this is somewhat informational at least. Its not terribly specific yet. Let folks know if you're needing more help, and we'll take it from there.