locked
Script block literals are not allowed in restricted language mode or a Data section RRS feed

  • Question

  • Here i execute power shell Scripts by using in C#:

    PSCredential psc = new PSCredential(@"domainname\username", SecurePswd);
    WSManConnectionInfo wsmConn = new WSManConnectionInfo(new Uri(strSystemURI), strShellURI, psc);
    Runspace rs = RunspaceFactory.CreateRunspace(wsmConn);
    rs.open();

    String Script = " Get-Mailbox adminuser Select-Object name,primarysmtpaddress, DisplayName,Database,@{e = {$MBXstat = Get-MailboxStatistics $_.name; $MBXstat.totalItemsize.value.toMB()}},@{e = {$MBXstat = Get-MailboxStatistics $_.name ; $MBXstat.itemcount}}";

    Pipeline pl = rs.CreatePipeline();
    pl.Commands.AddScript(Script);
    Collection<PSObject> psCol = pl.Invoke();//Here for me the error occurs "Script block literals are not allowed in restricted language mode or a Data section"

    If any knows why this occurs..Tel  me..Thanks a lot.


    • Edited by Vamsidaya Friday, May 3, 2013 7:21 AM
    Friday, May 3, 2013 7:21 AM

Answers

  • Maybe, this short quotation from this blog $(Get-Exchange).Info() will help you to narrow down the issue:

    "...
    PS C:\> Get-Mailbox
    Get-Mailbox : Value cannot be null.
    Parameter name: serverSettings
    At line:1 char:12
    + Get-Mailbox <<<<

    Why is this error, whenever you start Exchange Management Console or Exchange Management Shell, it initiates a Powershell Remoting Session, and sets some default settings such as the Domain Controller, the Exchange Server to connect etc. In above case these things didnt happen as we have just loaded the raw cmdlets using PSSnapin.

    Another important point to note is RBAC, when you load just the snapins, you are loading the raw cmdlets to the session.  Exchange is not intended to be managed like that. There is Robust Access Control layer built into the management tools, the Role Based Access Control (RBAC). When we do execute cmdlets by just loading PSSnapin it DOESNT RESPECT RBAC, and when RBAC is not respected the cmdlets may give unexpected results.

    PS: But this doenst block us from using the snapins to easily write or edit scripts, only thing is that you cannot run the scripts here.

    The solution is to use Implicit Remoting:

    In this method, we are not loading any Snapins, we just create an implicit remoting session using Import-PSSession and that session loads all the cmdlets we need,  it also respects the RBAC (So you only get access to the Cmdlets you have been assigned inside the RBAC Roles).

    Creating an Implicit Remoting session to Exchange Server 2010

    ..."

    So, it seems, you might give a solution involving 'Import-PSSession' a try. How exactly to use it, you'll find a short snippet as example on the site I cited above.

    wizend

    • Marked as answer by Yan Li_ Thursday, May 16, 2013 3:03 AM
    Tuesday, May 14, 2013 12:44 PM

All replies

  • I think your problem shows some parallels to the issue stated in this older thread. Please, check if the solution given there does also help in your case.

    Kind regards,

    wizend

    Friday, May 3, 2013 11:20 AM
  • Thanks for your reply Wizend.

    This is my script:

    Script =Get-Mailbox -ResultSize unlimited |Where{($_.UseDatabaseQuotaDefaults -eq $false)}

    If i use this script i am getting error like this "The term 'where.exe' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name,or if a path was included, verify that the path is correct and try again."

    If any knows why this occurs..Tel  me..Thanks a lot.

    Monday, May 6, 2013 11:04 AM
  • If your runspace is the Exchange server and you're running it in the remote management session provided by Exchange, you can only run the Exchange cmdlets. All the other cmdlets and powershell language elements are not recognised ( so answered by Mjolinor in this stackoverflow thread). You may have right the same issue.

    wizend

    Monday, May 6, 2013 2:05 PM
  • Thank for your reply Wizend.

    I have done like the things specified in the stackflow thread.

    Another new ERROR arises "No snap-ins have been registered for Windows PowerShell version 2."


    • Edited by Vamsidaya Tuesday, May 7, 2013 9:17 AM
    Tuesday, May 7, 2013 9:15 AM
  • While refering to the stackoverflow thread I had actually only the answer of Mjolinor in mind (just as I mentioned), where he stated that there are some constraints regarding the kind of cmdlets applicable for Exchange, but certainly not the solution, the OP of that thread finally found out by himself by tinkering with that Microsoft.SharePoint.PowerShell snap-in of his. That solution might fit for some others as well, but most likely it won't, because their environment and settings might not be comparable to his. Hope, you took care of that.
    Tuesday, May 7, 2013 10:31 AM
  • Thanks a lot Wizend...
    Wednesday, May 8, 2013 4:37 AM
  • Here i create a new session and run the poweshell cmdlets in that session,

    Cmdlets,

             $s=New-PSSession -ComputerName "Name" [Here the session gets created]

             invoke-command -Session '$s- scriptblock {Get-Mailbox adminuser} [Here the error occurs]

    Error:

    Value cannot be null.      
    Parameter name: serverSettings
        + CategoryInfo          : NotSpecified: (:) [Get-Mailbox], ArgumentNullException
        + FullyQualifiedErrorId : System.ArgumentNullException,Microsoft.Exchange.Management.RecipientTasks.GetMailbox.

    Any body knows y this kind of error occurs????Thanks a lot..........

    Monday, May 13, 2013 9:54 AM

  •          invoke-command -Session '$s- scriptblock {Get-Mailbox adminuser} [Here the error occurs]

    It seems so as if you 're escaping the '$' special character, that might lead to the shell not beeing able to read your $s variable. Try it again but without that leading "`". And set a space between "$s" and the following parameter "-SriptBlock {...}"

    • Edited by Wizend Monday, May 13, 2013 1:45 PM
    Monday, May 13, 2013 1:44 PM
  • thanks for your reply wizend,

                               i removed that (') and given space between $s and -.....but still same error occurs.

    cmdlet:

        invoke-command -Session $s -scriptblock{Get-Mailbox adminuser} 

    Tuesday, May 14, 2013 6:12 AM
  • Maybe, this short quotation from this blog $(Get-Exchange).Info() will help you to narrow down the issue:

    "...
    PS C:\> Get-Mailbox
    Get-Mailbox : Value cannot be null.
    Parameter name: serverSettings
    At line:1 char:12
    + Get-Mailbox <<<<

    Why is this error, whenever you start Exchange Management Console or Exchange Management Shell, it initiates a Powershell Remoting Session, and sets some default settings such as the Domain Controller, the Exchange Server to connect etc. In above case these things didnt happen as we have just loaded the raw cmdlets using PSSnapin.

    Another important point to note is RBAC, when you load just the snapins, you are loading the raw cmdlets to the session.  Exchange is not intended to be managed like that. There is Robust Access Control layer built into the management tools, the Role Based Access Control (RBAC). When we do execute cmdlets by just loading PSSnapin it DOESNT RESPECT RBAC, and when RBAC is not respected the cmdlets may give unexpected results.

    PS: But this doenst block us from using the snapins to easily write or edit scripts, only thing is that you cannot run the scripts here.

    The solution is to use Implicit Remoting:

    In this method, we are not loading any Snapins, we just create an implicit remoting session using Import-PSSession and that session loads all the cmdlets we need,  it also respects the RBAC (So you only get access to the Cmdlets you have been assigned inside the RBAC Roles).

    Creating an Implicit Remoting session to Exchange Server 2010

    ..."

    So, it seems, you might give a solution involving 'Import-PSSession' a try. How exactly to use it, you'll find a short snippet as example on the site I cited above.

    wizend

    • Marked as answer by Yan Li_ Thursday, May 16, 2013 3:03 AM
    Tuesday, May 14, 2013 12:44 PM
  • Thanks for your reply Wizend,

                      i created a new session and imported it and executed by commands..

    Link:

    http://blogs.msdn.com/b/akashb/archive/2011/07/30/how-to-get-information-on-database-copies-using-managed-code-and-remote-powershell-exchange-2010.aspx

    Saturday, June 15, 2013 6:41 AM