Access denied to list object when using powershell remoting with SharePoint

I came across this one today. Take the following example:

Enter-PSSession -ComputerName servername -Authentication Credssp -Credential domain\username
Add-PsSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
$SPWeb = Get-SPweb http://portal
$SPWeb.Lists

When you run the $SPWeb.Lists you will probably get an access denied. it’s a little strange since the account I was running with was not only a farm admin but also had full control to the web app via the user policy.

Turns out that you need to grant the identity you are using access to the content DBs.

$w = Get-SPWebApplication -Identity http://portal
$w.GrantAccessToProcessIdentity("domain\username")

Now rerun the commands and it should work.

Windows Update error code 8024402F on Hyper-V guests

OK so this was a weird one. I updated my lab environment which runs on a Windows 8 Hyper-V install. I tried installing the pre-requirements for SharePoint 2013 but it kept failing. I then tried running Windows Update and got a code 8024402F. Everything that people were saying indicated that it was indicating a connection issue. Um, what? I can browse the web on this VM, why isn’t it windows update working? After some digging online I found a response to a post about a similar question.

http://www.experts-exchange.com/Microsoft/Applications/Virtual_Server/Hyper-V/Q_26941221.html

The poster blamed the offloading settings on the broadcom NIC they were using. Mine is a realtek, however when I checked it did have offloading settings. I decided what the heck and disabled the following NIC adapter settings.

  • ARP offloading
  • Large send offloading
  • TCP checksum offloading
  • UDP checksum offloading

Example below:

Windows Update error code 8024402F on Hyper-V guests

 

After disabling the offloading features shown above, the SharePoint 2013 pre-requisite installer started actually working. One of those quirks of running a Hyper-V lab I guess.

Update: well I guess I was wrong on this. the issue started happening again. I’ll update the post when I find the resolution.

Update: Its been a while since I updated this but I was not able to find an easy solution with the existing setup. I ended up buying a dedicated NIC for the hyper-v guests. So the system has two, one for the guests and another dedicated for the OS.

Calendar entries in Exchange/Outlook duplicate out of control and possible excessive transaction log growth

I feel a little late to the party on this but I ran across this issue today. http://support.microsoft.com/kb/2814847. There is an issue in iOS 6.1 that can cause calendar entries to start duplicating out of control. A side effect is that it will also cause transaction logs to grow out of control as well.

According to the article there isn’t much that can be done to prevent it. The official recommendations as of this posting are to:

  • Remove and recreate the device partnership
  • Create a custom throttling policy
  • Block all iOS 6.1 users

Removing the recreating the partnership does seem to work in the one case I’ve dealt with so far. Still this is a very nasty issue due to the transaction log growth. the throttling policy will help mitigate the issue but not stop it. It will just slow the mailbox totaldeleteditemsize and log growth.

One option for proactively detecting users where this is happening is to compare the totaldeleteditemsize from an hour or two ago to what it’s currently at now.

Get-MailboxStatistics -Database DBname | select displayname,TotalItemSize,TotalDeletedItemSize,ItemCount | sort ItemCount -Descending

Thats good for a visual inspection but if you need something that can be alerted on the following script also works. It compares a previous value of totaldeleteditemsize to the current value for all users on a server (I tried all org users and the result size broke poweshell) and then reports anyone who has had that value grow over 1 GB since the last run. a time of 1-2 hours between runs should be good enough to get results. The results can then be reviewed to see if there is cause for concern and investigated further.

$server = "servername"

$yesterfilename = $server + "_yesterusersizes.txt"
$filename = $server + "_usersizes.txt"

Remove-Item $yesterfilename -Force -Confirm:$False
Rename-Item $filename -NewName $yesterfilename -Force -Confirm:$False

Get-Mailbox -Server $server -ResultSize Unlimited | Get-MailboxStatistics | select displayname,@{label=”TotalItemSizeMB”;expression={$_.TotalItemSize.Value.ToMB()}},@{label=”TotalDeletedItemSizeMB”;expression={$_.TotalDeletedItemSize.Value.ToMB()}},ItemCount,LegacyDN | sort TotalDeletedItemSizeMB -Descending | Export-Csv -NoTypeInformation $filename

$yesteruserssizes = Import-Csv $yesterfilename

Foreach ($user in $yesteruserssizes) {
    $Current = Get-MailboxStatistics $user.LegacyDN | select displayname,@{label=”TotalItemSizeMB”;expression={$_.TotalItemSize.Value.ToMB()}},@{label=”TotalDeletedItemSizeMB”;expression={$_.TotalDeletedItemSize.Value.ToMB()}},ItemCount,LegacyDN

    $diff = $Current.TotalDeletedItemSizeMB - $user.TotalDeletedItemSizeMB
    If ($diff -gt 1024) {
        $Current | ft
        Write-Host "Delta for" $current.displayname":" $Diff | out-file -Append Report.txt -Force
    }
}

No word on if this is fixed in iOS 6.1.1 that I’ve heard about.

I also saw this blog post which does a very good job of describing the issue and expands a bit more on MS’ workarounds. http://eightwone.com/2013/02/08/yaii-or-yet-another-iphone-issue/

Update 2013-02-14: Apple has release an article about the issue. http://support.apple.com/kb/TS4532. It explains that the issue occurs when you respond to a modification to a single event in a meeting series. Apparently a fix is coming in an update. No word when that will be though.

Update 2013-02-19: Apple released 6.1.2. Apparently this does fix the issue. YAY!

Disable autodiscover methods in Outlook 2013

There is this KB article to reference and Outlook 2007 and 2010 ADM files http://support.microsoft.com/kb/2612922. The ADM files attached to the article were greate because they gave a way to disable the different methods Outlook uses to determine autodiscover in Outlook 2007 and 2010. Outlook (generically) uses 5 methods to determine discoverer.

  1. SCP object lookup
  2. Root domain query based on your primary SMTP address
  3. Query for the AutoDiscover domain
  4. HTTP redirect
  5. SRV record query in DNS

Unfortunately Outlook 2013 is a little new and MS doesn’t have a nice precanned ADM. Thats ok because the exact same methods for autodiscover are used in 2013 as they were in previous version.

I was able to create a reg file for 2013 by exporting the key that gets created when the ADM is applied via GPO for 2010 and just changing the registry path. So instead of:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover

I changed it to:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\Outlook\AutoDiscover

You can change the various options from the registry file as well. They are:

“ExcludeScpLookup”=dword:00000001
“ExcludeHttpsRootDomain”=dword:00000000
“ExcludeHttpsAutoDiscoverDomain”=dword:00000000
“ExcludeHttpRedirect”=dword:00000000
“ExcludeSrvRecord”=dword:00000000

Above the SCP lookup is disabled.

I’ve attached a registry file that can be imported that will disable the SCP look up in Outlook 2013. You can change the values in the reg file to suit your needs.

Outlook2013

SharePoint, Exchange and other things.

%d bloggers like this: