Weirder is that the ZIP/Postal Code fields on the Account, Lead, and Contact entities are searchable by default. Weird only because they use the same underlying table (CustomerAddress).

Keep this in mind when you wonder why you can’t search for additional addresses by ZIP code. Make that ZIP/Postal Code field on the Address entity searchable, and you’re good . . .

→ Read More: Dynamics CRM doesn’t enable search on Address ZIP/Postal Code by default]]> In the “oh my, how did that slip through?” category comes this one: in Dynamics CRM 2011, the ZIP/Postal Code field on the Address (CustomerAddress) entity is not searchable by default.

Weirder is that the ZIP/Postal Code fields on the Account, Lead, and Contact entities are searchable by default. Weird only because they use the same underlying table (CustomerAddress).

Keep this in mind when you wonder why you can’t search for additional addresses by ZIP code. Make that ZIP/Postal Code field on the Address entity searchable, and you’re good to go.

System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive.

For the FTP upload, I was using the .Net FtpWebRequest class, in a rather simple code snippet:

The FTP connection was dropping, but why? The transfer file was rather large (over 50MB), but reading the MSDN documentation for the FtpWebRequest.Timeout property, it was pretty clear that the .Net Framework wasn’t timing out, because:

FtpWebRequest.Timeout Property

Type: System.Int32 An Int32 value that contains the number of milliseconds to wait before a request times out. The default value is Infinite.

I tried active and passive connections; both failed. I checked the firewall; nothing unusual. I tried other external servers; they all failed. What gives?

Finally, exasperated, I tried forcing the timeout:

For example, take the following configuration:

Dynamics CRM with IFD requires a combination of ADFS relaying party trusts and DNS configuration to get things working. One caveat with IFDs is that the internal and external host names for the Dynamics CRM front-end servers must be different because, externally, the host name includes the CRM organization name. . . .

→ Read More: URL Rewriting for user-friendly URLs with Dynamics CRM 2011]]> Anyone who has attempted to configure Dynamics CRM 2011 with an Internet-Facing Deployment (IFD) knows that it is no trivial task. Where there are blog posts that discuss setting up an IFD, and Microsoft documentation for configuring the IFD, they often assume that ADFS and Dynamics CRM are installed on the same server, and that there is only one Dynamics CRM front-end server. Unfortunately, real-world implementations don’t always follow that.

For example, take the following configuration:

• a Dynamics CRM front-end server on the internal network, providing services to internal clients
• a Dynamics CRM front-end server in an Internet-facing zone, providing services to external clients
• a separate ADFS server accessible to internal and external clients

Dynamics CRM with IFD requires a combination of ADFS relaying party trusts and DNS configuration to get things working. One caveat with IFDs is that the internal and external host names for the Dynamics CRM front-end servers must be different because, externally, the host name includes the CRM organization name. Where, internally, you may have https://icrm.contoso.com/crm, externally you would have https://crm.contoso.com.

Let’s flesh out our sample implementation and requirements:

• icrm.contoso.com is our internal Dynamics CRM front-end server, accessible only on the internal network
• ecrm.contoso.com is our external Dynamics CRM front-end server, accessible to our internal network and the public Internet
• adfs.contoso.com is our ADFS server, accessible to our internal network and the public Internet
• We have two Dynamics CRM organizations: CRM and CRM-Test.
• We want our internal and external (public Internet) clients to access CRM using the same URLs: crm.contoso.com and crm-test.contoso.com. In other words, we don’t want the two-URL problem outlined above.

The last bit has nothing to do with Dynamics CRM: it is all done in IIS. Let me explain how.

IFD Host Names and DNS Configuration

In order to get Dynamics CRM configured for the IFD, your internal DNS and external DNS must be set as needed to allow internal and external clients to resolve to all Dynamics CRM and ADFS host names.

One poorly-documented part of the IFD setup is what the host names should point to in the Internet Facing Deployment Configuration Wizard. The Discovery Web Service Domain (something like dev.contoso.com) and the “external domain where your Internet-facing servers are located” (something like auth.contoso.com) must both resolve to a Dynamics CRM front-end server, not the ADFS server. Be sure to set up these host names to resolve to your internal/external Dynamics CRM servers.

So, in our sample environment, our internal and external DNS has the following entries:

• contoso.com zone:
  • icrm (internal DNS only)
  • ecrm (internal and external DNS)
  • adfs (internal and external DNS)
  • auth (internal and external DNS, points to icrm internally and ecrm externally)
  • dev (internal and external DNS, points to icrm internally and ecrm externally)
  • crm (internal and external DNS, points to ecrm internally and externally)
  • crm-test (internal and external DNS, points to ecrm internally and externally)

The DNS configuration, if wrong, at best, will break your IFD, and at worst break all access to Dynamics CRM, so be sure to get it right. If you get it right, and you configure the IFD right, your setup would work as follows:

• Internal clients access CRM at https://icrm.contoso.com/CRM and https://icrm.contoso.com/CRM-Test. No ADFS authentication is required.
• External clients access CRM at https://crm.contoso.com and https://crm-test.contoso.com. ADFS authentication is required.

This unfortunately is not what we want. Instead, we want our users to use the external client domains whether they are internal or external. To do this requires no change to Dynamics CRM; rather, the solution is through Internet Information Services (IIS).

Rewriting URLs with IIS

Here’s what happens with the above configuration:

1. User enters https://crm.contoso.com or https://crm-test.contoso.com in their browser.
2. The request is sent to the internal Dynamics CRM server, icrm.contoso.com.
3. Dynamics CRM calls ADFS to get credentials for the user.
4. ADFS can’t resolve the user’s credentials, because the host name is not known to ADFS.
5. User can’t access Dynamics CRM.

Here’s what needs to happen:

1. User enters https://crm.contoso.com or https://crm-test.contoso.com in their browser.
2. The request is sent to the internal Dynamics CRM server, ecrm.contoso.com.
3. IIS and the URL Rewrite module running on ecrm.contoso.com examine the request and identifies it as coming from an internal client (by IP address).
4. If the request is coming from an internal client, IIS redirects the client to https://icrm.contoso.com/crm or https://icrm.contoso.com/crm-test.
5. Everything else works as expected.

URL Rewriting rules live in the web.config file in the Dynamics CRM installation directory (by default, C:\Program Files\Microsoft Dynamics CRM\CRMWeb). Open this file and add the following to the <rules> section.

<rule name="Redirect Internal Connections" stopProcessing="true">
<match url="(.*)" />
<conditions trackAllCaptures="true">
<add input="{REMOTE_ADDR}" pattern="192\.168\.[0-9]{1,3}\.[0-9]{1,3}" />
<add input="{HTTP_HOST}" pattern="([^\.]*)\.(.*)" />
</conditions>
<action type="Redirect" url="https://icrm.contoso.com/{C:1}/{R:1}" appendQueryString="true" redirectType="Found" />
</rule>

The only changes you need to make to the above are:

1. Change the regular expression pattern in the REMOTE_ADDR line to match your internal IP addresses. (Google has a nice tool to help with this.)
2. Change the url in the Redirect line to match the host name of your internal Dynamics CRM server.

Do that, test it extensively (internally and externally), and then tell your users that the one URL they use to access Dynamics CRM is the only one they need to remember.

Error deleting a managed solution: State code or status code is invalid State code is invalid or state code is valid but status code is invalid for a specified state code.

The ErrorDetails.txt file states the following — note the text in bold.

Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: 1 is not a valid status code for state code SavedQueryState.Inactive on savedquery.Detail:

Error Code -2147187704

CallStack at Microsoft.Crm.Extensibility.VersionedPluginProxyStepBase.Execute(PipelineExecutionContext context) at Microsoft.Crm.Extensibility.Pipeline.Execute(PipelineExecutionContext context) at Microsoft.Crm.Extensibility.MessageProcessor.Execute(PipelineExecutionContext context) at Microsoft.Crm.Extensibility.InternalMessageDispatcher.Execute(PipelineExecutionContext context) at Microsoft.Crm.Extensibility.ExternalMessageDispatcher.ExecuteInternal(IInProcessOrganizationServiceFactory serviceFactory, IPlatformMessageDispatcherFactory dispatcherFactory, String messageName, String requestName, Int32 primaryObjectTypeCode, Int32 secondaryObjectTypeCode, ParameterCollection fields, CorrelationToken correlationToken, CallerOriginToken originToken, UserAuth userAuth, Guid callerId, Guid transactionContextId, Int32 invocationSource, Nullable`1 requestId, Version endpointVersion) at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.ExecuteRequest(OrganizationRequest request, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType) at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.Execute(OrganizationRequest request, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType)

This error came about after we marked some of the out-of-the-box views as Inactive (like “Accounts: Responded to Campaigns in Last 6 Months”). Looking at the database, the . . .

→ Read More: Fixing ‘State code or status code is invalid’ errors when deleting solutions in Dynamics CRM 2011]]> Working with Dynamics CRM 2011, I started getting an error when attempting to delete a managed solution:

Error deleting a managed solution: State code or status code is invalid
State code is invalid or state code is valid but status code is invalid for a specified state code.

The ErrorDetails.txt file states the following — note the text in bold.

Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: 1 is not a valid status code for state code SavedQueryState.Inactive on savedquery.Detail:

Error Code -2147187704

CallStack
at Microsoft.Crm.Extensibility.VersionedPluginProxyStepBase.Execute(PipelineExecutionContext context)
at Microsoft.Crm.Extensibility.Pipeline.Execute(PipelineExecutionContext context)
at Microsoft.Crm.Extensibility.MessageProcessor.Execute(PipelineExecutionContext context)
at Microsoft.Crm.Extensibility.InternalMessageDispatcher.Execute(PipelineExecutionContext context)
at Microsoft.Crm.Extensibility.ExternalMessageDispatcher.ExecuteInternal(IInProcessOrganizationServiceFactory serviceFactory, IPlatformMessageDispatcherFactory dispatcherFactory, String messageName, String requestName, Int32 primaryObjectTypeCode, Int32 secondaryObjectTypeCode, ParameterCollection fields, CorrelationToken correlationToken, CallerOriginToken originToken, UserAuth userAuth, Guid callerId, Guid transactionContextId, Int32 invocationSource, Nullable`1 requestId, Version endpointVersion)
at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.ExecuteRequest(OrganizationRequest request, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType)
at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.Execute(OrganizationRequest request, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType)

This error came about after we marked some of the out-of-the-box views as Inactive (like “Accounts: Responded to Campaigns in Last 6 Months”). Looking at the database, the statecode (Status) and statuscode (Status Reason) for these views (in table SavedQueryBase) were both “1″. There was a simple workaround to this: change the statuscode to “2″, using the following SQL.

update savedquerybase
set statuscode = 2
where statuscode = 1
and statecode = 1

That allowed the solution to delete without error, and the views I wanted inactivated were still inactive. Seems a bug in Dynamics CRM 2011, but I can’t say for sure.

Of course, use this as your own risk!

Unfortunately, authenticating to https://crm.company.com didn’t work for Internet Explorer users. IE would prompt for the credentials, but they were never accepted. Authentication did work for other browsers, and all browsers — including IE — were able to authenticate to https://crmserver01.company.com without issue.

This didn’t make sense. The domain name of the server shouldn’t matter (both were in IE’s Local Intranet Zone), nor should the browser version. But the different experience between browsers was all I had to go on, so I did some (network) sniffing.

Using Fiddler2 to monitor the network traffic created by web browsers, I opened Firefox and connected to http://crm.company.com (no SSL, so it’s easier to monitor network traffic). Firefox . . .

→ Read More: Troubleshooting Windows Authentication in IIS]]> In a recent deployment of Microsoft Dynamics CRM 2011, users were accessing the application via the server’s host name, e.g. https://crmserver01.company.com. That is rather unfriendly, so we created a new DNS record for crm.company.com — giving users the easier-to-remember https://crm.company.com (and removing a dependency on a server name).

Unfortunately, authenticating to https://crm.company.com didn’t work for Internet Explorer users. IE would prompt for the credentials, but they were never accepted. Authentication did work for other browsers, and all browsers — including IE — were able to authenticate to https://crmserver01.company.com without issue.

This didn’t make sense. The domain name of the server shouldn’t matter (both were in IE’s Local Intranet Zone), nor should the browser version. But the different experience between browsers was all I had to go on, so I did some (network) sniffing.

Using Fiddler2 to monitor the network traffic created by web browsers, I opened Firefox and connected to http://crm.company.com (no SSL, so it’s easier to monitor network traffic). Firefox prompted me for my password, I typed it in, and was taken to the Dynamics CRM “unsupported browser” page. (That lack of support for non-IE browsers is a separate issue, but a fix is supposedly in the works.)

Here’s what Fiddler reported for those requests. I’ve truncated the request/response text to only show what’s relevant.

1. Request
   GET http://crm.company.com
2. Response
   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: Negotiate
   WWW-Authenticate: NTLM
3. Request
   GET http://crm.company.com
   Authorization: NTLM <token>

The responses after that don’t matter; I’m connected. I then did the same steps with Internet Explorer: connected to http://crm.company.com, get prompted for the password, type the password, get prompted again, wash rinse repeat two times, then get the boilerplate “401 Unauthorize” page. Here’s the Fiddler report:

1. Request
   GET http://crm.company.com
2. Response
   HTTP/1.1 401 Unauthorized
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
3. Request
   GET http://crm.company.com
Authorization: Negotiate <token>

Note the difference? Firefox uses NTLM to authenticate; IE uses Negotiate (Kerberos). This was the root of the problem: Kerberos isn’t permitted to authorize users accessing crm.company.com, but it is permitted to authorize users accessing crmserver01.company.com. NTLM doesn’t have that restriction. So, it’ll always work in non-IE (non-Kerberos) browsers; and it will work to the host name URL in IE browsers; but it won’t work to the alternate host name in IE.

How do you fix this? By reading the blog post, Configuring and Troubleshooting NTLM and Kerberos on Windows 7 (Windows Server 2008) and IIS7. Essentially, you tell the server to allow Kerberos to the “other” domain name by running the following command from the console: setspn -A HTTP/crm.company.com crmserver01

Another solution is to configure your web site to only use NTLM authentication, or to give NTLM authentication higher priority than Kerberos. However, this is more a workaround than a fix: the point of IE/Windows is to use Kerberos, not to avoid it. Still, it’s an option if you can’t run the setspn command for some reason.

Once you do either of those, all browsers will work to either domain name, as you would expect, and your users will be happy.

To set the “ownerid” I used the DBLOOKUP command to look up the team by name, and return the teamid: DBLOOKUP( “MyTeamName”, “CRM”, “team”, “name”, “teamid” ). This worked fine, but on its own, Dynamics threw an error, saying that the GUID wasn’t valid.

The problem lies in how Dynamics manages owners: an owner can be a user or a team. The owner of an entity is assumed to be a user unless you change the “owneridtype” field, which is visible in Scribe but is not . . .

→ Read More: Setting the entity owner to a team using Scribe Insight and Dynamics CRM 2011]]> While working on migrating data from a legacy CRM system to Microsoft Dynamics CRM 2011 using Scribe Insight, I decided to set the owner of all migrated entities to a specific team (rather than the default, which is the Dynamics user specified in the Scribe connection). To do this seemingly would require one simple steps: to look up the GUID of the team, and set the value of the Dynamics CRM “ownerid” to that value.

To set the “ownerid” I used the DBLOOKUP command to look up the team by name, and return the teamid: DBLOOKUP( “MyTeamName”, “CRM”, “team”, “name”, “teamid” ). This worked fine, but on its own, Dynamics threw an error, saying that the GUID wasn’t valid.

The problem lies in how Dynamics manages owners: an owner can be a user or a team. The owner of an entity is assumed to be a user unless you change the “owneridtype” field, which is visible in Scribe but is not listed in the Dynamics data dictionary (as far as I could tell). If the owner is a user, the “useridtype” should be 8. If the owner is a team, the “useridtype” should be 9.

After setting the “useridtype” to 9, Dynamics accepted the GUID of my team in the “ownerid” field. Problem solved!

Below is a summary of my experience.

First, I go to the Product & Service summary page on the My Account page.

Then, I click on Registration Keys.

Then, I choose the appropriate version (2011) and upgrade option (No) and get the following message: “The keys you are trying are of Volume license, hence they will not be shown from MBS.” (I have no idea what MBS is.)

Frustrated, I try getting support by clicking the support link on the “Contact Dynamics Operations” page.

Which yields a very unhelpful support page that tells me, “Our apologies…An unexpected error occurred.” At least they are apologetic.

Despairingly, I click the ROC Contact Information at the bottom of the page (I have no idea . . .

→ Read More: An exercise in frustration: Getting product keys and support using the Microsoft Dynamics CustomerSource web site]]> “Microsoft Dynamics CustomerSource is an information-packed, password-protected site for customers who use Microsoft Dynamics products.” (Microsoft’s words, not mine.) I decided to use this information-packed, password-protected site to get my recently purchased product keys for Dynamics CRM 2011.

Below is a summary of my experience.

First, I go to the Product & Service summary page on the My Account page.

Then, I click on Registration Keys.

Then, I choose the appropriate version (2011) and upgrade option (No) and get the following message: “The keys you are trying are of Volume license, hence they will not be shown from MBS.” (I have no idea what MBS is.)

Frustrated, I try getting support by clicking the support link on the “Contact Dynamics Operations” page.

Which yields a very unhelpful support page that tells me, “Our apologies…An unexpected error occurred.” At least they are apologetic.

Despairingly, I click the ROC Contact Information at the bottom of the page (I have no idea what “ROC” is) and get a different apologetic error.

Pretty unimpressive, even for Microsoft.

A little less farther back, in 2007, I tried convincing some people at Microsoft to let the community continue development of these adapters, and they agreed. The CSSFriendly CodePlex project was born, and a bunch of bugs and some new features were added.

A lot has changed since then, but the adapters still have use today for people stuck on .Net 2.0 (they’re in the top 200 most downloaded CodePlex projects, and their forums still see activity). To facilitate those who still use CSSFriendly, I’ve added the library package to NuGet.

How to use the CSSFriendly NuGet package

In four easy steps (three if you already have NuGet).

Suppose that every day, ten men go out for beer and the bill for all ten comes to $100. If they paid their bill the way we pay our taxes, it would go something like this…

The first four men (the poorest) would pay nothing The fifth would pay $1 The sixth would pay $3 The seventh would pay $7 The eighth would pay $12 The ninth would pay $18 The tenth man (the richest) would pay $59

So, that’s what they decided to do.

The ten men drank in the bar every day and seemed quite happy with the arrangement, until one day, the owner threw them a curve ball. “Since you are all such good customers,” he said, “I’m going to reduce the cost of your daily beer by $20″. Drinks for the ten . . .

→ Read More: Beer and Taxes]]> The following has been circulated around for a long time. It just resurfaced to me, and I wanted to share it! I wish I knew who to credit it to.

Suppose that every day, ten men go out for beer and the bill for all ten comes to $100.
If they paid their bill the way we pay our taxes, it would go something like this…

The first four men (the poorest) would pay nothing
The fifth would pay $1
The sixth would pay $3
The seventh would pay $7
The eighth would pay $12
The ninth would pay $18
The tenth man (the richest) would pay $59

So, that’s what they decided to do.

The ten men drank in the bar every day and seemed quite happy with the arrangement, until one day, the owner threw them a curve ball. “Since you are all such good customers,” he said, “I’m going to reduce the cost of your daily beer by $20″. Drinks for the ten men would now cost just $80.

The group still wanted to pay their bill the way we pay our taxes. So the first four men were unaffected. They would still drink for free. But what about the other six men ? How could they divide the $20 windfall so that everyone would get his fair share?

They realized that $20 divided by six is $3.33. But if they subtracted that from everybody’s share, then the fifth man and the sixth man would each end up being paid to drink his beer.

So, the bar owner suggested that it would be fair to reduce each man’s bill by a higher percentage the poorer he was, to follow the principle of the tax system they had been using, and he proceeded to work out the amounts he suggested that each should now pay.

And so the fifth man, like the first four, now paid nothing (100% saving).
The sixth now paid $2 instead of $3 (33% saving).
The seventh now paid $5 instead of $7 (28% saving).
The eighth now paid $9 instead of $12 (25% saving).
The ninth now paid $14 instead of $18 (22% saving).
The tenth now paid $49 instead of $59 (16% saving).

Each of the six was better off than before. And the first four continued to drink for free. But, once outside the bar, the men began to compare their savings.

“I only got a dollar out of the $20 saving,” declared the sixth man. He pointed to the tenth man,”but he got $10!”

“Yeah, that’s right,” exclaimed the fifth man. “I only saved a dollar too. It’s unfair that he got ten times more benefit than me!”

“That’s true!” shouted the seventh man. “Why should he get $10 back, when I got only $2? The wealthy get all the breaks!”

“Wait a minute,” yelled the first four men in unison, “we didn’t get anything at all. This new tax system exploits the poor!”

The nine men surrounded the tenth and beat him up.

The next night the tenth man didn’t show up for drinks so the nine sat down and had their beers without him. But when it came time to pay the bill, they discovered something important. They didn’t have enough money between all of them for even half of the bill!

]]> http://www.sidesofmarch.com/index.php/archive/2011/04/25/beer-and-taxes/feed/ 1 http://www.sidesofmarch.com/index.php/archive/2011/03/22/insufficient-pagefile-size-can-cause-obscure-memory-errors/ http://www.sidesofmarch.com/index.php/archive/2011/03/22/insufficient-pagefile-size-can-cause-obscure-memory-errors/#comments Tue, 22 Mar 2011 16:26:36 +0000 brian http://www.sidesofmarch.com/?p=523 Today, a user reported an issue connecting to a very old CRM application. I logged in to the system myself and saw no error. Since I’m not happy with self-healing issues, I went digging into the event log on the server.

For the past five days, there have been over 15,000 entries added to the System event log with event ID 333: “An I/O operation initiated by the Registry failed unrecoverably. The Registry could not read in, or write out, or flush, one of the files that contain the system’s image of the Registry.” That doesn’t sound good.

My first stop for analyzing event log errors is eventid.net. The feedback on their site pointed me to a few possibilities.

The /3GB switch on a system with 2GB or less of memory. Symantec AntiVirus (which is a potential culprit to every system problem, apparently). Insufficient Non Paged Memory . . .

→ Read More: Insufficient pagefile size can cause obscure memory errors]]> Today, a user reported an issue connecting to a very old CRM application. I logged in to the system myself and saw no error. Since I’m not happy with self-healing issues, I went digging into the event log on the server.

For the past five days, there have been over 15,000 entries added to the System event log with event ID 333: “An I/O operation initiated by the Registry failed unrecoverably. The Registry could not read in, or write out, or flush, one of the files that contain the system’s image of the Registry.” That doesn’t sound good.

My first stop for analyzing event log errors is eventid.net. The feedback on their site pointed me to a few possibilities.

• The /3GB switch on a system with 2GB or less of memory.
• Symantec AntiVirus (which is a potential culprit to every system problem, apparently).
• Insufficient Non Paged Memory or Paged Pool Memory.
• Disk or I/O subsystem errors.
• Overaggressive SQL Server memory usage or I/O affinity.

I checked the server’s memory capacity: 3GB. I checked memory usage in Task Manager: about the same. I checked the page file size, and saw the following (note the highlighted sections).

Ouch! Microsoft has a nice knowledge base article, affectionately titled, RAM, Virtual Memory, Pagefile, and all that stuff, which suggests, as a baseline recommendation, that a pagefile should equal “1.5 times the amount of RAM that is in the computer.” As always, your mileage may vary, but generally speaking, the recommendation is sound. Or, you can just click the “System managed size” option, and forget about it altogether.

The lesson here: check your pagefile settings when setting up a computer, and always revisit them whenever the amount of physical RAM changes.

]]> http://www.sidesofmarch.com/index.php/archive/2011/03/22/insufficient-pagefile-size-can-cause-obscure-memory-errors/feed/ 0