A week back I upgraded my Exchange environment from E2K10 SP1 to E2K10 SP3.
Since then, I am unable to export mailboxes with New->MailboxExportRequest powershell script. Even though, I'm having right permission to export the mailboxes.
The cmdlet which I'm making use of is this:
New-MailboxExportRequest-Mailbox user-FilePath \\MailServer\PST\user.pst
The above cmdlet is identified and it is has been queued permanently.
Can anyone tell me why this has happened?
Did you have a DAG?
Have you tried to restart the Exchange Mailbox Replication service on all CAS servers to verify the result?
I suggest you to check the status of this mailbox database if it is mounted. You can use the following command to check this.
Get-MailboxDatabaseCopyStatus -Identity "mailbox database name"
Alongside, please make use of the Get-MoveRequestStatistics cmdlet to view full information about move requests.
Related
We were trying to deliver a solution to manage a Windows 2012 server for a client using Chef, but unfortunately chef-client run failed with Chef::Exceptions::WindowsNotAdmin: can not get the security information for <some_file> due to missing Administrator privileges exception.
This was a bit weird as we have confirmed that the domain account we used to remotely manage the server is a member of the Administrators group. And we were able to use it to manage other servers within the same domain. Besides, when we connected to the server using the domain account via Remote Desktop, started PowerShell as an administrator and initiated a chef-client run, it failed with the same exception.
Running below commands reveals that the domain account is indeed a member of the Administrators group. This can be verified by the SID of the group.
Get-WmiObject -Class Win32_UserAccount
Get-WmiObject -Class Win32_Group
[System.Security.Principal.WindowsIdentity]::GetCurrent().Groups
Not sure what settings on the server could have caused this.
With insights provided by this thread, further digging into the code of Chef reveals that a win32 function GetNamedSecurityInfoW gets called here to determine the security information of an object (file, folder etc.). This occurs during cookbook installation where some resource files or gems need to be created on the endpoint server.
Firstly an empty file will be created, after that the file content will be updated atomically if that is an option. During file content update, the file’s security access control list needs to be checked by the function GetNamedSecurityInfoW. To call this function, the logged-on user needs to have a privilege SE_SECURITY_NAME. Chef itself also tries to handle this by adding this privilege before calling the function and revert it after the function call, but this is not always guaranteed. System settings seem to prevail.
We hacked Chef code a bit to try to print out the output of the function call on GetNamedSecurityInfoW, and it was a status code 1314, indicating a required privilege is not held by the user.
We tried to run whoami /priv on the server and found that SeSecurityPrivilege privilege is not found in the list. Below is just a sample output on a normal Windows server.
Privilege Name Description State
========================================================================
SeLockMemoryPrivilege Lock pages in memory Disabled
SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled
SeSecurityPrivilege Manage auditing and security log Disabled
...
Note that the state column only indicates whether a privilege is being used by the user. It's existence indicates whether the user has it or not.
After adding back this privilege to the domain account, i.e. set the security setting of Manage auditing and security log to Administrators group in the Local Securtiy Policy editor, and rebooting the server, chef-client run became successful.
It seems that Chef is heavily using win32 API functions to manage Windows nodes. And these API functions seem to need various privileges to run. It's a bit strange that Chef rescued all win32 API errors and just propagated the Chef::Exceptions::WindowsNotAdmin to chef-client run log, as indicated here. It would be good to actually parse the error a bit and provide some more useful information.
We had an issue with our Exchange 2010 outlook or server and for some reasons we had all our user receiving internally and externally duplicated mails with the same message ID.
I know there are third party software we can buy and we are not allowed to do so.
Is there any code we can run on PowerShell to delete all the duplicated mails on the all mailboxes on the server?
thanks
Mes
There is this script (https://gallery.technet.microsoft.com/office/Removing-Duplicate-Items-f706e1cc) which suggested by Microsoft, but you must specify the user mailbox.
Put this script to that destination
C:\Program Files\Microsoft\Exchange\Web Services\1.2
After that use this command:
.\Remove-DuplicateItems.ps1
-Mailbox "user#domain.com"
-Type All
-Impersonation
-DeleteMode HardDelete
-Mode Full
-Verbose
You can change the delete mode to 'SoftDelete' or 'MoveToDeletedItems' etc.
I am looking for a tool to know if a given computer on the local network is being remotely accessed by a user or not and ideally I'd like to know who that user is. In my company, we share virtual machines and we keep have to ask members in the team if they use any remote computer. I'd like to have some kind of dashboard that can tell me what computer is being used, and what computer is free.
I am happy to use any kind of commercial solution that would require the install of services on each of the machines that need to be monitored or things like that.
The below is made easier if you're querying from a Windows client joined to the same domain as the system you are querying, and may require certain rights above and beyond a standard domain user. If you run into authentication/permission issues, that would be the first thing I'd check.
There is a tool available at least as far back as Windows XP called "qwinsta". Later versions of Windows have both qwinsta and "query session".
qwinsta /server:computer01
SESSIONNAME USERNAME ID STATE TYPE DEVICE
console 0 Conn wdcon
rdp-tcp 65536 Listen rdpwd
administrator 2 Disc rdpwd
That shows user "administrator" logged in but disconnected. Since in this example computer01 is a Windows Server 2003 system with the default "administration" RDP license, there's a second session listening for someone to connect.
Running the same command again after connecting to that previously disconnected session looks like this:
SESSIONNAME USERNAME ID STATE TYPE DEVICE
[unchanged output removed]
rdp-tcp#25 administrator 2 Active rdpwd
This is enough to answer "is someone currently active via RDP", and if you're using individual usernames, it should answer the "who" as well. If you're all using "testuser" or "administrator" or something, you'll probably want to know the answer to "from what client", and that is not given above.
The above gives a quick basic answer without needing additional tools. For more detailed information, you might look at the cassia library or PSTerminalServices (built on cassia). See some of the answers in this question for more detail.
My first thought on this was to use Sysinternals tools such as PsLoggedOn or LogonSessions. I then found reference to the previously-unknown-to-me qwinsta and rwinsta tools in this blog post from 2003.
You can use a PSModule named PSRdSessions, this module provide some simple funtions
sample of use
Get-RdSession -ComputerName Server01.domain.xyz # return [Cassia.Impl.TerminalServicesSession]
for return [hashtable]
Get-RdSession -ComputerName Server01.domain.xyz | Convert-RdSession # return
for return [pscustomobject]
Get-RdSession -ComputerName Server01.domain.xyz | Convert-RdSession | %{[pscustomobject]$_}
I'm trying to use impersonation in my application to connect to user mailboxes and add/remove appointments.
I created an account called "EWSAdmin" and ran the following EMS commands on them:
New-ManagementScope -Name:"MyEWSImpersonation" -RecipientRestrictionFilter
{memberofgroup -eq "cn=My User Container,DC=MyDomain,DC=local"}
New-ManagementRoleAssignment -Name:"MyEWSImpersonation" -Role:ApplicationImpersonation
-User:"EWSAdmin#MyDomain.local" -CustomRecipientWriteScope:"MyEWSImpersonation"
Just to confuse the issue, I called my scope EWSImpersonation, too.
When I try to connect to the user's mailbox to view an appointment (Using a third party DLL), I get the following error:
Throwing GeneralException e=The account does not have permission to
impersonate the requested user.
If anybody could help me diagnose this, I'd appreciate it.
Thanks
Nick
We ran into this issue with a different cause, I want to share it here because when searching for the error message this post and a post on TechNet come up, but not the KB Articles that eventually helped us solve the issue.
It turns out that there is a limit to the amount of requests any windows server can do to Active Directory, at some point the NetLogon service just runs out of Threads and all kinds of things start to happen. The process is explained in this blog post and this KB article and this KB article, the fix is pretty simple, increase the number of threads available through a simple change to a Registry key on every CAS server in the Exchange cluster.
The process is simple:
Start Registry Editor.
Locate the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Create the following registry entry:
Name: MaxConcurrentApi
Type: REG_DWORD
Value: Set the value to the larger number, which you tested (any number greater than the default value).
At a command prompt, run net stop netlogon, and then run net start netlogon.
Notes
The maximum value that can be configured depends on the operating system version and whether a hotfix is available.
The maximum configurable setting in Windows Server 2003 is 10.
The maximum configurable setting in Windows Server 2008 (without the hotfix in this article) is 10. With the hotfix, the maximum is 150.
The maximum configurable setting in Windows Server 2008 R2 (without the hotfix in this article) is 10. With the hotfix, the maximum is 150.
If you decide to increase the MaxConcurrentApivalue to greater than 10, the load and the performance of the desired setting should be tested in a nonproduction environment before you implement in production. This is recommended to make sure that increasing this value does not cause other resource bottlenecks.
I know almost nothing about "admin" side of setting up impersonation for EWS but maybe you can take a look at this article and compare your actions with what this guy did to make it work
http://www.thesoftwaregorilla.com/2010/06/exchange-web-services-example-part-3-exchange-impersonation/
in my company admin setup impersonation according to msdn and it works for me so I presume it can't be so hard and probably you missed some steps or maybe that 3rd party dll needs some additional magic.
link to msdn article in case you didn't know it: http://msdn.microsoft.com/en-us/library/bb204095.aspx
It would be nice to have an example for E2010 as it is not as easy as 2007.
Here is an example to creating EWS impersonation for a group. Any member of the group would be impersonated by the service account. Just add additional members to the group as requirements demand. Two steps...create the New Management scope and then the Role assignment.
New-ManagementScope “Scope Name” -RecipientRestrictionFilter {(MemberOfGroup -eq 'CN=group name,CN=Users,DC=Contoso,DC=com')}
New-ManagementRoleAssignment -Name “EWS ROLE NAME” -Role applicationimpersonation -User Domain\Service Account -CustomRecipientWriteScope “Scope Name”
Where “Scope Name” is the management scope created in step one.
We have an Exchange Server running, we're trying to connect with it from an application in another server. Thing is, we have to set some permissions for it to work (we want to access any mailbox with an Administrator mailbox, but we have to set it Full Mailbox Access first). We somehow need to set this for every new user at the moment it's created. Could you tell us how do we do that?
Thanks in advance.
Here is one way to do it.
http://support.microsoft.com/kb/821897
Another way to do this is , type following command in the Exchange Management Shell
Add-MailboxPermission -Identity "" -User "" -AccessRights FullAccess -InheritanceType All
Using Exchange Management Shell commands, you can do many useful things easily.