I'm trying to create an appointment only using PowerShell. Is anyone here who knows how to do that?
I've already tried to use EWS, but I'm not sure how to do that right.
Thank you for every answer!
It is not clear where you run the PowerShell script...
You may consider automating Outlook for creating an appointment item. Read more about that in the Outlook Email Automation with PowerShell article.
However, Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
Related
Is a VSTO application considered a macro as far as office is concerned? In other words, will macro sensitive antivirus software give me trouble? And will the Word trust Center settings need to be changed to allow macros?
Thanks.
A VSTO app is totally different from a VBA macro, and should not trigger any macro-related warnings. A macro is a script attached to the document; simply opening an office document could trigger some potentially harmful VBA code, without warning to the user. By contrast, a VSTO app is a .NET app which needs to be explicitly installed and accepted by the user on his machine.
Mathias gave us an excellent answer. I totally agree with that. But I also just want to add a little bit more things about VSTO here based on some of my own experiences.
VSTO add-in is basically an application-level extension for MS Office. It requires .NET framework & VSTO runtime to be installed on the target machine in order to run correctly (In some case, PIA is needed as well). VSTO runtime is not too good in terms of compatibility, and greatly dependent on Office version. For example, Office 2003 doesn't work with VSTO 4.
Using VSTO opens opportunity for .net programmers who'd like to create MS Office based applications. It certainly is more powerful than what VBA can offer.
But the downside of any VSTO application is the challenges in deployment. Although ClickOnce approach is meant to make the whole deployment a bit easier, the process is still not as easy as falling off a log, especially for deployment using Windows Installer approach. Special registry keys, permissions, and all that just give you a headache from time to time. Also API is not documented very well, code examples aren't enough either... Well, anyway, I think VSTO still has its potentials and hopefully Microsoft will provide better support in the near future and more people join community of VSTO development.
I have deployed my web application (ASP.NET/C#) on the Server (Win 2003) to make it possible to merge word documents and open them.
Everything worked fine: a .doc ducment was added to the bottom of another .doc document (using Microsoft.Office.Interop.Word libraries) and then opened with the client MS Word.
Unfortunately in the weekend an automatic update has been done on the Server by another team and I do not know yet which kind of update was done (maybe an Office 2003 Update, but it might be even a Server patch).
Anyway after that I get the following Warning in the Event Viewer and the application hangs when it comes to use Microsoft.Office.Interop.Word libraries:
Detection of product '{90110409-6000-11D3-8CFE-0150048383C9}',
feature 'OfficeUserData', component '{4A31E933-6F67-11D2-AAA2-00A0C90F57B0}' failed.
The resource 'HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\MS Access Database\' does not exist.
We do not even use MS Access, but SQL Server instead.
What I fear is that registry keys have been changed and now the system does not work anymore as expected.
I set the "NETWORK SERVICE" user with privileges to access/launch word and it is the same user used also for the Default App Pool. We use IIS6, Windows Server 2003 e Word 2003.
Could suggest any approach of solution? (even if I know that without knowing which update has been done, it might be hard).
Thanks
Using and Office components (beit Office itself or the PIAs) on a server is to be avoided at all costs:
Microsoft does not currently
recommend, and does not support,
Automation of Microsoft Office
applications from any unattended,
non-interactive client application or
component (including ASP, ASP.NET,
DCOM, and NT Services), because Office
may exhibit unstable behavior and/or
deadlock when Office is run in this
environment.
Microsoft KB article
Like many others, I am regularly confronted with this problem and there is no easy solution.
Either dedicate a little server somewhere to do your Office stuff (and be prepared to reboot it regularly) or use a third-party product that doesn't reference the PIAs.
Sorry to be the bringer of bad tidings...
You should be able to check under the Windows updates to see what updates were recently applied. Hopefully, you could roll them back until you find the culprit.
Paul's right. Deploying a solution using MSOffice apps on a server can be a +very+ dicey proposition. Be prepared, and make use of watchdog timers and code to enumerate and kill errant WINWORD.EXE processes when you think it might have dropped off the deep end. it's not elegant stuff, but it can be made to work.
As for 3'rd party tools, I've looked at A LOT of them. If you're building a doc from scratch, most are ok, though they have varying levels of implemented functionality.
If you can work with DOCX files exclusively, the OpenDoc XML SDK works quite nicely and is free. But it sucks to actually manipulate existing documents.
If you're planning on using existing documents as templates, you're options become much more narrow. You can do it with the OpenXML SDK, but it's VERY difficult. Windward reports works, but can be $$$.
Most of the "Word Compatible" libraries for sale don't implement all the functionality you're likely to need.
You'll most likely find that using the Word Object Model API is the only route to give you the capability you'll need. But, as always YMMV.
My team and I are designing a diagnostic test tool as part of our next product. The test tool will exercise a request/response API and display asynchronous events. As part of the diagnostic tool suite, we will also be providing cmdlets for the entire product API.
Is it worth embedding PowerShell execution into the tool UI ? What are other development teams doing ?
The scripts can still run stand alone in any PowerShell window or tool. From a user's perspective, they would gain the ability to launch scripts from our UI. And, since the UI can be monitoring the same devices that the scripts act on, it brings some unity to the execution of a script and monitoring of the results. Embedding script execution brings more work to the project and I'm not sure how we want to handle displaying the results of the scripts.
Do most PowerShell users expect to run their scripts from their own shell environments or within tools that come from their product vendors ? Note, our diagnostic tool will not be automatically generating scripts for the users as some Microsoft tools do (it might be valuable for inexperienced PowerShell users, but we are expecting most scripts to be fairly simple, like executing a command on a series of devices).
Fortunately embedding the PowerShell engine and execute commands/scripts and getting the results back is pretty trivial. That said, I'm not sure you scenario is one where I would embed PowerShell. You ask if folks prefer to run scripts from their own shells or from within the Tool Vendors environment. I can't speak for everybody but the shells and editors that I use support some nifty features for debugging, code folding, syntax highlighting, multiple runspaces, etc. I'm not sure you would want to go through the effort to provide similar capabilities.
One reason to embed PowerShell is to execute the same PowerShell cmdlets as part of your core diagnostics and monitoring engine. That way you don't have to duplicate functionality between your diagnostic tool app engine and the cmdlets that your customers use for automation. It sounds like the code you use to do the diagnostics and monitoring in the app is different than the code in the cmdlets? Or is there common code shared between the app and the cmdlets?
Another reason to embed PowerShell is to allow the app itself to be scriptable but this doesn't appear to fit your scenario.
Another reason to embed PowerShell is if you are implementing a new host - ie you provide some unique editing or shell functionality. Some apps that do this are PowerGUI (which allows you to launch scripts IIRC) and PowerShell Plus.
Yet another reason I have embedded PowerShell in an application is because I knew I could get certain results in much less code than the equivalent C# code. This is a weaker reason and I probably wouldn't do this in a commercial app but I have used this for one-off programs.
I agree with both Jaykul and Keith Hill - the answer is yes.
There are several approaches you could use. But in general, I'd recommend you a) create key cmdlets as part of the UI for your app and b) you build the GUI on top of PowerShell (in the same way the Exchange team has done.
Doing this follows Microsoft's lead (all applications have to have a PowerShell interface) that is also being taken up by others (e.g. VMware, and even Symantec leverage PowerShell in their applications.
Creating cmdlets (and possibly a provider) is pretty straightforward - there's a great cmdlet designer recently released (see http://blogs.msdn.com/powershell/archive/2009/10/16/announcing-open-source-powershell-cmdlet-and-help-designer.aspx) for this tool.
Hope this helps!
Yeah, the main reason I'd consider actually embedding PowerShell in that scenario is if your UI could generate PowerShell scripts for the actions the users take in the UI, so they could see what was happening, and easily learn how to automate it. That would require designing the UI based on PowerShell from the beginning ... so it sounds to me like you're better off just providing the cmdlets and samples ;)
Microsoft seems to be heavily pushing that their server applications (i.e SQL Server 2008, Exchange Server, etc) all have some type of PowerShell integration. The logic makes sense in that one can choose to manage the application from a GUI or CLI.
Therefore if one were to follow that trend and want to build an application that had a PowerShell interface, how would one even start?
Has anyone in the community done this type of thing? If so, what seems to be the best approach?
Update:
The UI needs to have a certain look/feel. Therefore, PowerGUI does not lend itself in this situation. However, I've used PowerGUI and do agree that it can help bridge gaps.
Part of the confusion is really whether or not hosting PowerShell is necessary in order to build an application on top of it. From what I've found, it is not (i.e. Cmdlet's). However, I have not seen anyone really discuss this in the answers yet.
Start here: Writing a Windows PowerShell Host Application
Exchange 2007 admin console hosts PS directly, and surfaces every UI action by showing a ubiquitous "and here's the PowerShell you just asked me to do" UI model). SQL Server 2005 & 8 admin consoles demo the concept of surfacing everything in a UI as scripts as a way of dogfooding scripting abilities (but there is little PowerShell support in SQL Server) (Distinction between Exchange and SQL Server's type of support added in response Shaw's comment, thanks)
PowerScripting podcast has a few interviews on topics like this. Also get-scripting podcast
I attended a PowerShell / MMC 3.0 Devlab at Microsoft a few years ago that taught how to do this very thing. The basic idea was to create the "management functionality" via a series of PowerShell cmdlets in a PSSnapin for your application. CLI oriented folks can just load the snapin and party on your cmdlets directly. For the GUI oriented, you build a MMC snapin that hosts a PowerShell runspace which, in response to GUI actions, executes the appropriate PowerShell cmdlets to tweak the application that is being managed. For bonus points, you display what PowerShell code will be executed by the MMC GUI such that the code can be copied and pasted into a script. There are plenty of examples out on the web that show how to host a PowerShell runspace in your (or the MMC) process and execute PowerShell script in that runspace and get back results.
This is an intriguing idea!
I haven't ever thought about it, and I have no idea if I think it's a good idea, but some creative things could be done.
For example, suppose you have some typical administrative-ish piece of software. Don't really care what, specifically. In a classic app dev't scenario, I'd typically try to generate a list of Command objects (things that'd implement some sort of ICommand), and then my UI would bind to those.
Suppose, now, that you were to instead create a cmdlet for each Command. The UI would more-or-less exist as a friendly interface for the core logic in the suite of cmdlets.
Yeah, ok, nothing new here. People've been doing this for a long time, building up GUIs around command-line tools. I think the key difference is that you'd instead be building up individual command line tools from the concept of the application itself. Heck, it might make more sense for both the application and the cmdlets to reference some shared library of commands instead of making the GUI sit on top of the cmdlets themselves.
Errr- sorry for the scatterbrained response. This answer was pretty much purely stream-of-consciousness. :)
You could try primal forms for building a complete application from a script or you need to build your application with an snappin cmdlets (the previous being what is used by sql, exchange etc.) but link to primail forms here
http://www.primaltools.com/products/info.asp?p=PrimalForms
We are discussing development of an improved management infrastructure for our distributed system.
We use COM, web services and .NET components. Since we're based on Microsoft Windows Server XP/2003, I guess, we basically have two options:
Powershell cmdlets
WMI classes using System.Management and WMI providers for native code (class, instance, method, event)
Why would we choose Powershell over WMI?
I would choose PowerShell over WMI for the following reasons:
Writing a cmdlet is only adding a .NET Class.
The PowerShell runtime provides command line parsing built in.
Writing your management interface in PowerShell allows administrators the ability to integrate management of your application with that of other applications and services (like Exchange, Active Directory, or SQL Server).
The PowerShell environment makes the pipeline available to administrators, enabling management tasks for your application to be done more efficiently.
Discoverability. PowerShell, via Get-Command, Get-Member, and Get-Help, provides an extremely discoverable environment for admins to work in, resulting in a shorter learning curve to maintaining your application.
Even if you go the WMI route, PowerShell does have support for working with WMI (though there are a few glitches).
To me, PowerShell is the best way to surface a task oriented interface to an application. With the support Microsoft has been providing PowerShell, it is and will be a consistent interface to managing applications and services throughout the enterprise.
My day job is as an admin and I'm pushing all the vendors I work with towards surfacing a PowerShell management API, as this makes the learning curve and context switching for managing applications much lower. On the development side, I have written (and am still working on) a series of PowerShell cmdlets for one open source product I work with and am working on another set for a separate application.
Jeffrey Snover answers the "why PowerShell" here. The post is in the context of SQL, but very much applicable here.
I'm not sure I'd make the decision. It's not exactly either-or... you can choose to do both.
WMI can be consumed by a number of different things, not just PowerShell. Why not write your management instrumentation in PowerShell, and then wrap that WMI in some task-oriented cmdlets to make things easier on administrators? That's what some MS product teams are choosing to do, especially when they have other consumers of WMI they want to continue supporting.
If you've already got suitable .NET code, turning that into a cmdlet may be faster than turning it into a WMI provider. If that's the case, and speed is a concern, go with what's easier. But no matter what you do, you can always wrap it in a PowerShell cmdlet for admins, which is definitely the recommended approach.
Not sure that this can be answered with the information that you have provided so far. My gut feeling would be that you should use powershell since it sounds like you may already have some .Net code. But it really does just depend on exactly what you are trying to do.