Login to Central Administration(SharePoint3.0) and navigate to >> Application Management >> Web Application General Setting page, in this page change the Maximum upload size value.

The default value for Sharepoint uploads is 50MB.

I had this issue recently on a Server 2012 machine. It was because I was running the command in the commend prompt without administrator rights.

If you start CMD with Administrator Rights, and run the command, the copy will run fine

Whenever you update Lync Server, there is a manual command needed in order to update the Database.

Lync Server 2010-2013 Standard Edition

Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn SE.FQDN -Verbose

Using Powershell, it’s very simple to change product keys on your Server 2012 deployment.

slmgr -ipk XXXX-XXXX-XXXX-XXXX (this installs the new Product Key)

Make sure you run as administrator or it will yell at you to run with administrator privledges!

It took me a while to figure this one out. I kept getting DNS errors in my console and also I wasn’t able to Live Migrations on VMs. The information from the failed live migration basically told me, The machine just failed to migrate, no idea why, good luck figuring it out.

I then looked at my cluster and saw that there was a ton of errors in the event logs related to DNS. Triple checked every DNS setting but basically couldn’t figure out why it was complaining about not being able to find the record.

The solution is this:

Give your cluster name inside of DNS full rights to itself. Open the DNS console, find your cluster service, right click and confirm the clusternname$ object has full rights.

Then once completed, you need to repair your cluster.

To this you need to bring your cluster offline (it will not affect the VMs running on it)

However, don’t take your cluster offline at the root. Instead, make sure you take it offline under where it says

Cluster Core Resources

This is towards the very bottom of the screen when you have left clicked on your root cluster.

Right click the cluster and say take offline.

Then under more actions, click Repair.

It will automatically bring your cluster back online and the errors will stop. Then run a test live migration and confirm it completes without error.

Since becoming an Audiocodes partner, I’ve run into this a few times now. I can’t seem to ever get it straight so I figured I would note the work around so that others may benefit.

This is the error I was getting

Then we need to export the configuration by running the following command

Export-CsConfiguration -FileName “C:\Config.zip”

This will output the configuration to a zip file that you need to transfer over to your SBA

Once the file is transferred your’ll need to run the command to import it

Import-CSConfiguration -Verbose -LocalStore -FileName “C:\config.zip”

Once the import is complete, go back to your SBA and you’ll need to skip that step and go onto Enable Replication. This will complete successfully and you’ll be able to continue setting up the SBA.

I just setup failover on a Fortigate with multiple ISP’s and I found that there was not a lot of documentation on the subject. Therefore, I am writing an article about it.

There are 3 places where you need to define objects and put in settings

BTW, The Fortigate that I am using is a Fortigate 60C v4.0 MR3 Patch

System -> Network -> Interface

I used WAN2, editing the settings and defined it accordingly by putting in the IP address and subnet mask.

Then under Router -> Static Route

You’ll need to setup another route to device, WAN2 and make sure you set the distance greater than 10, I set my primary to 10 and my secondary to 20.

Then goto Settings, here is where you define your “Ping Server”. In the new versions, it’s called the Dead Gateway Detection. Make sure your interface is the primary, in my case, it was WAN1, the Ping Server, should be a server that is basically always available, and then I set for ICMP Ping Protocol with an Interval of 5 and Failover of 5.

Lastly, you’ll need to create a new policy for Any/Any from Internal to WAN2. You can copy your WAN1 policy and just need to change the interface to WAN2.

This should complete the setup and allow for automatic failover!

I just ran into a situation where this fix would have saved me some time.

I went to upgrade my Exchange 2010 SP1 server to SP2 when I got this error

Setup previously failed while performing the action “Install”. You can’t resume setup by performing the action “BuildToBuildUpgrade”.

Basically what this means is that one of the roles you selected to install did not get installed properly.

The easiest way to find out which one is to run your orginal setup again and it’ll tell you which ones still need to be installed.

Another way is to look in the registry in the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14

There you will find listed the 4 roles

MailboxRole
ClientAccessRole
HubTransportRole

Whichever role is NOT installed properly will have a water mark called Action which is set to Install.

My recommendation would be to go back and figure out why it’s not installed properly. If nothing can be found, you can delete the key in order to get error to go away. That doesn’t mean however that the overall issue will be resolved once the SP gets installed.

I was configuring a new Cisco ASA when I get this error trying to map port 443 to my interface IP address.

After some research, I found that the management access was configured to allow ASDM access from the outside network. Natively, this port uses port 443. Once I removed access from the ASDM from the outside interface, I was able to create the rule as I needed it.

It’s not good practice to have the ASDM be accessed from the outside. If you need to allow anything, I would recommend using SSH and making sure it’s locked down to only external IP address that you trust.

0.0.0.0 0.0.0.0 is not your friend.

I setup a new Edge server for a client that ended up having a bunch of issues starting services. I wanted to write this article because the issues that I saw were very simple errors but took me a good amount of time to figure out.

The first issue I had was that none of the Edge services would start. If you tried to start an Edge Service, you would get an error in the event logs.

To check the Lync Event Logs:

I was seeing these errors in the event log:

Lync Server, Event 14352, LS Protocol Stack

Error: 0xC3E93C0A (SIP_E_STACK_TRANSPORT_FAILED)

AND

Lync Server, Event 14336, LS Protocol Stack

Transport TLS has failed to start on local IP address 4.4.4.4 at port 5061 (4.4.4.4 would be my Public IP address)

At first, the public IP was correct but the event log said LOCAL IP.

I checked Topology Viewer and everything looked ok. Under Edge Server, it said the FQDN of my account, say, access.ittech4life.com and then the public IP which was correct.

I double checked another installation and realized that the public IP should NOT be listed but the DMZ IP address of that object. I changed in topology viewer and rebooted the Edge Server. Those errors went away but now I had a new error:

Lync Server, Event 22037, LS A/V Edge Server

Cause: An IP address and/or listening ports may be configured incorrectly.

I looked again at topology viewer but this time everything was correct. I also checked the NIC card configuration and found my issue. My subnet was 192.168.110.x but one of the IPs was mistakenly put in for 192.168.100.x. I changed to the correct subnet, rebooted again and all my issues were solved.

Just goes to show you that double checking the initial configuration can save you a lot of work later on.