We are working on a project that will require us to determine the exact role of an Exchange server through WMI, using Perl. It looks as if there was a WMI namespace for Exchange that was deprecated some time ago (possibly with 2003?). Is there a way to query through WMI to determine the role of an individual server for Exchange 2007/2010/2013?
No, WMI is not supported in versions of Exchange starting with Exchange 2007. Per Development technologies for earlier versions of Exchange, the Exchange Management Shell is the recommended replacement for WMI -"Exchange Management Shell commands that work with versions of Exchange starting with Exchange 2007 replace the WMI providers in Exchange 2003. Because Exchange Management Shell commands that enable you to control Exchange servers, storage groups, databases, and users are easier to use than the corresponding WMI providers and objects, you can easily migrate your applications to Exchange Management Shell commands." Hope that helps!
Related
Does Red-Gate SQL Compare need to be installed on On-Premise Database Server to run powershell scripts that are set for automation? I have Red-Gate on my local machine, and I am asking this question to figure out if i need to install it to server because that will determine if i need to buy another license.
There are subtleties in licensing that are best discussed in person with Redgate Sales. It will depend on whether you are the only user contributing to the database changes and triggering the automation, what 'user' will be running the automated process (is it you, or will it be drive by a service account?) If you contact sales#red-gate.com (or your Redgate account executive) they will be able to advise you on your options.
We have an overweight an bloated email account on Exchange 2007 running on a SBS 2008 which needs emptying, but not deleting. unfortunately there was no monitoring in place and now it's slowing the entire network down (another long story)...
What would be the easiest and most efficient way to remove all emails from the offending email account please?
Thanks
You need to grant access and setup shell scripts in Exchange Management Shell. Just use these shell commands to make your job easier.
http://community.spiceworks.com/how_to/show/892-delete-emails-in-exchange-2007
Let's say I would like to check some user mailbox properties from within PowerShell. I can run the script in Exchange Management Shell but the problem is that I have no guarantee that the end user will be running the script directly on Exchange or a machine with any Exchange tools. So, I can tell the end user to just run the script in the PowerShell (not EMS) and encode importing pssesion into the script.
However, here comes the main problem of mine, I cannot hard-code the server name into the script (it will be used in many different environments) and I would like to avoid asking the end user to provide the Exchange Server name for the pssesion.
Is there any way to obtain the Exchange Server name automatically with just vanilla PowerShell (no EMS, etc.)? The script will be ran by users with domain admin privileges, most likely there will be no Outlook on the machines (so no MAPI profiles configuration), if that is of any help.
I'm not sure how portable this is (it works on my E2K7 setup, but your mileage may vary)...
You can look in AD to get a list of exchange servers by doing something like the following:
$exchangeServers = [ADSI]"LDAP://contoso.com/CN=Exchange Servers,OU=Microsoft Exchange Security Groups,DC=contoso,DC=com"
$exchangeServers.Member
In my environment, this lists all of the exchange server computer accounts, plus a few other groups, but it's a starting point.
I need to connect to an Exchange 2010 server using C# and Powershell. The Exchange 2007 Docs want me to add a snap in
RunspaceConfiguration rsConfig = RunspaceConfiguration.Create();
PSSnapInException snapInException = null;
PSSnapInInfo info = rsConfig.AddPSSnapIn("Microsoft.Exchange.Management.PowerShell.Admin", out snapInException);
Runspace myRunSpace = RunspaceFactory.CreateRunspace(rsConfig);
myRunSpace.Open(rsConfig);
Other samples on the net want me to use WSMan like this
WSManConnectionInfo connectionInfo = new WSManConnectionInfo(false, "ExchangeServer.ibm.com", 80, "/Powershell", "http://schemas.microsoft.com/powershell/Microsoft.Exchange", credential);
So my questions are:
What is the effective difference between these techniques?
Are they interchangeable?
In Exchange 2007 you used a management snapin in a local runspace to run the cmdlets. All the changes were made under your credentials.
In Exchange 2010 that changed. Maintenance is done through a remote session provided by the Exchange server. The actual changes are done by the Exchange server on your behalf using a proxy account, and Exchange determines whether you're authorized to make those changes according to the RBAC roles you belong to. The changes are logged in the Admin Audit log.
There is a snapin for Exchange 2010, but using it by adding it into a local session is not supported by MS, and not all of the cmdlets work properly in that environment. Most cmdlets do work, but it bypasses RBAC, and and any changes made in that environment do not get logged to the Admin Audit Log.
Your first example is simply instantiating a new Runspace on the local system, which does not use WS-MAN. The second portion is leveraging the WS-MAN service, which requires that you configure it on all of the systems you'll be connecting to ahead of time.
To be honest, if you don't need to use WS-MAN to connect to a remote system, I would just avoid it and use the Exchange team's recommended practice. WS-MAN is (read: can be) fairly simple to set up and use, but it adds a layer of complexity that may simply be unnecessary, and cause additional troubleshooting headaches.
Is there such a thing as a shell-based command-line client for Microsoft's Jet database engine?
Something similar to SQLite 3.x (sqlite3.exe) for SQLite.
Will PowerShell be suitable? Fellow MVP Richard Siddaway has started a very interesting series of blog postings on using PowerShell and Access. You can ignore the Office 2010 tag on his blog postings. Also note that I know nothing about PowerShell.
This may suit:
Cscript.exe is a command-line version
of the Windows Script Host that
provides command-line options for
setting script properties.
With Cscript.exe, you can run scripts
by typing the name of a script file at
the command prompt. Like Microsoft
Internet Explorer, Windows Script Host
serves as a controller of Windows
Script compliant scripting engines,
but Windows Script Host has very low
memory requirements. Windows Script
Host is ideal for both interactive and
non-interactive scripting needs, such
as logon scripting and administrative
scripting.
Windows Script Host supports scripts
written in VBScript or JScript.
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/wsh_runfromcommandprompt.mspx?mfr=true
Something like osql with the right data provider? http://msdn.microsoft.com/en-us/library/aa214012(SQL.80).aspx
Entering the conversation here 10 years after the original question, but I've played with a couple of tools that should work:
YouAccess (http://youaccess.sourceforge.net): "YouAccess is a free (donationware) lifesaver console µapplication intended for SQL management of Microsoft® Access™ databases from command line, including creating them."
JetSQLConsole (https://sourceforge.net/projects/jetsqlconsole): "A command line/console interface for Microsoft Access databases, very similar to the MySQL client application."